Acute Logic & Lead CCTV PE-1005S HD Camera Module - Page 1
Forum section: electronics / projects

author: dexters_lab
author_rank: Unknown
timestamp: September 28, 2019, 08:50:51 am
content: Over in the for sale section several forum members have picked up some of these high-def camera modules. I thought i'd start this thread so we can pool some resources together and see if we can get something meaningful out of the cameras.https://www.eevblog.com/forum/buysellwanted/cameras-uk-burnley)/The module is a HD video camera with upto 1080p30 output as '16bit YUV 4:2:2' which could mean several things TBH, i am going to hazard a guess it's something like bt.601 butThe maker is indicated as ACUTE Logic. A Japanese company they seem to have sold their camera module business to a Chinese company in 2011 so i guess these cameras predate that.https://www.acutelogic.co.jp/en/http://www.leadcctv.net/PE1005S.htmlI have emailed both companies to see if we can get some documentation for themSpec & Features:1 1/2.5 inch 5.0 MegaPixel Progressive CMOS sensor2 Full HD（1920x1080/30p）high resolution Color Camera Module3 Video Output: supports 25 configurable format4 Lens: 10X Optical Zoom, Approx.1 cm wide macro5 Ultra-low-power design (≤800mw at 1080P/30 video output)6 Dynamic digital image stabilization design (DIS)7 3A Auto Control technology (AF, AE, AWB)8 Defective pixel correction, Jitter correction, Backlight compensation9 Day/Night: AutoParameter:1 1/2.5 inch 5.0 MegaPixel Progressive CMOS sensor2 Full HD Resolution 1920×1080/30p3 Lens: 10X Optical Zoom，Focus f=4.5 - 45.0mm, Aperture f1.8 - 2.24 Min illumination: 6 Lux / 0.35 Lux (High sensitivity mode / slow shutter)5 Output: 16 bit YUV 4:2:26 Control Interface : I2C7 Power supply: 2.8v, 4.0v8 Power consumption: ≤800mw9 Weight: 57g10 Operating temperature: -10℃ ~ 60℃11 Size: 30.9mm(W) x 34.7mm(H) x 61.8mm(D)Functional:1 Defective pixel correction / Jitter correction / Backlight compensation2 Flicker Cancel: Auto/Off/Manual（50Hz/60Hz）3 EV （-2EV~+2EV ）, Resolution 1/3 EV4 ISO: Auto/Manual（6 step）5 Auto slow shutter: On/Off6 The zoom morement direction and speed settings / read current zoom position7 AWB: Auto/Daylight/Cloudy/Shade/Fluorescent light(white/normal/day)/Tungsten/Custom/Manual(specify x, y)8 Sharpness: High/Mediun/Low9 Noise Reduction: High/Mediun/Low/Off10 WDR

author: Mjolinor
author_rank: Frequent Contributor
timestamp: September 29, 2019, 02:36:54 pm
content: I am sure I have more docs but for the moment can only find this:Edit: Found some more. There is an XLS file here where I started working out the connections but didn't get too far.I am sure you know all about that.

author: Yansi
author_rank: Super Contributor
timestamp: September 29, 2019, 02:43:04 pm
content: Looking forward to seeing some progress with this.

author: dexters_lab
author_rank: Unknown
timestamp: September 30, 2019, 10:35:56 am
content: i heard back from Acute Logic with a nice polite reply to goto the Chinese company the tech was sold to... so nothing there. We'll see what we can get from LeadCCTV in China.

author: CJay
author_rank: Super Contributor
timestamp: October 02, 2019, 04:09:29 pm
content: I've seen this device under the Hitachi banner too which may be a useful source of information if anyone has old data, if we know the vintage it may be possible to track down contemporary products but I *think* this unit was intended for videoconferencing equipment

author: Jon86
author_rank: Frequent Contributor
timestamp: October 04, 2019, 12:25:24 pm
content: Has anyone had any luck getting in touch with these companies?I sent LeadCCTV an email regarding their HDMI adapter boards a few days ago and still no reply. Chrome won't let me translate their website either so I'm not sure where to go from here.It's one of the very few things on their website so if they're still going I'd imagine they'd be quite keen to sell them!

author: CJay
author_rank: Super Contributor
timestamp: October 04, 2019, 08:31:11 pm
content: Close but no cigar (yet)https://web.archive.org/web/20120803204044/http://www.leadcctv.net/news00.htmlThere's a Leonid Tochinsky with some experience here:http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/t/155094#Maybe someone with a TI account can see if he's still active and ask?Nope, got it:https://wenku.baidu.com/view/26977f0b03d8ce2f00662322.html

author: dexters_lab
author_rank: Unknown
timestamp: October 10, 2019, 07:55:03 am
content: Hardware specification attached, lots more tech detail in this one including connector & pinout specification. though nothing for the i2c protocol which is in a separate document that i have already asked for.Important details:Connector is a Panasonic AXT360264Power is two rails 4v @ 450ma and 2.8v @ 270maThere is a PON signal, pulled high by the host for power onDefault video mode is 1920x1080 @ 30 fpsVideo is indeed YUV 4:2:2, there's 16 data lines, clock, H sync and V sync. The Y and C is a combined word, so you get a luma and a chroma sample on every rising clock.lower 8 bits are the luma contentupper 8 bits are chroma Cb or CrClock is 66mhz, this seems to be fixed regardless of the video modeThe most ideal output for me would be 1080p25 as HD-SDI

author: PlainName
author_rank: Super Contributor
timestamp: October 10, 2019, 08:21:52 am
content: Good going, that man

author: dexters_lab
author_rank: Unknown
timestamp: October 10, 2019, 10:49:22 am
content: some slight confusion about the connector... the camera datasheet says it's AXT360264 but that doesn't exist according to Panasonic, i think it should be AXT360224 for the socket and AXT460124 for the headeravailable at Farnell:https://uk.farnell.com/panasonic-electronic-components/axt460124/conn-stacking-header-60pos-2row/dp/2916666

author: dexters_lab
author_rank: Unknown
timestamp: October 10, 2019, 12:03:46 pm
content: and here is the i2c protocol spec

author: dexters_lab
author_rank: Unknown
timestamp: October 11, 2019, 04:06:54 pm
content: Out of interest how many people out there want to help or have one of these cameras?

author: PlainName
author_rank: Super Contributor
timestamp: October 11, 2019, 04:34:30 pm
content: I have a couple but I'm too busy at the moment to do anything with 'em. Stockpiling info for when they top the queue

author: Mjolinor
author_rank: Frequent Contributor
timestamp: October 14, 2019, 07:38:59 am
content: I think 7 or 8 (trouble counting that high me).Still a full tray left

author: dexters_lab
author_rank: Unknown
timestamp: October 16, 2019, 07:43:01 am
content: It doesn't seem like there's much going on from this thread but that's not the case.ElectronAsh (https://twitter.com/AshEvans81) is on board and has a couple of the cameras, over the last day or so we have looked at it in detail, he's designing a PCB that the camera will mount directly onto and will include an fpga that he can use as some kind of development mule. It's not really a recommended solution, to have the camera board-to-board but we figured lets just get this up and making a picture before we start getting fancy with flat-flex cables and stuff.Currently it's looking like camera -> fpga/ram -> hdmiThe picture is probably going to be buffered in ram first, issues with the clock timing mean this is probably inevitableWe did look into HD-SDI as an output but we couldn't find any suitable SDI serialisers that were cheap enough and not BGA. HDMI can be converted to SDI anyway pretty cheap. In the future we could potentially include a SMPTE compliant parallel output for connection to a serialiser.Will keep you all posted.

author: PlainName
author_rank: Super Contributor
timestamp: October 16, 2019, 09:08:57 am
content: Sounds brill

author: dexters_lab
author_rank: Unknown
timestamp: October 29, 2019, 07:55:31 am
content: quick update,ElectronAsh has been working on a PCB for this just to get something up and running, it's essentially FPGA and HDMI as that is what Ash works with all the time. The camera is mounted directly on the PCB to save the expense of a flat flex.He's just about to order a few of these boards and will be doing all the work on the FPGA, funding the PCBs and component purchase himself, so we can't thank him enough! Those of us interested in getting these cameras working should consider helping him out with some extra funds as things progress.

author: PlainName
author_rank: Super Contributor
timestamp: October 30, 2019, 10:30:34 am
content: Happy to chip in, within reason. Is he going to flog the completed boards or what?

author: OzOnE
author_rank: Regular Contributor
timestamp: October 30, 2019, 01:28:47 pm
content: Hi,Firstly, a big thanks to Mjolinor for offering the cameras, and sending me a few. Very generous of you.It's going to be tricky for me atm to get a batch of boards assembled by a company, mainly due to finances and time, as I'm working on many different projects atm.I'm hoping to build two or three boards first, then confirm they work OK. I don't like to release anything until it's tested obviously.I've tried to double-check what I can on the design, like the measurements for the header to the cam module, distances for the mounting holes, supply rails for the FPGA IO banks, which pins on the cam module needed pull-ups or tied to GND/VCC etc.This is my first project using the MAX10, though, so that may require a few tweaks if I've missed something.My usual go-to FPGA has been the Cyclone III for the past 4-5 years, as it can still be bought in the TQFP144 package for manual soldering. I've yet to get my reflow oven up-and-running so I can start using BGA stuff.The MAX10 does have a fair few advantages. It frees up more IO pins (and every one is precious. lol), does away with one or two extra voltage regs, since it can run on a single 3V3 supply, and obviously it doesn't require external SPI Flash for configuration, so there's a slight saving there.I'll be sending off for say 5 PCBs via PCBway in the next day or two, but I've been trying to get a couple of other designs done in the mean time, so I can get them shipped all at once.If I don't manage to finish the other designs by about the weekend, I'll just order the 5 camera board PCBs, then build a few myself.I've used the ADV7513 HDMI chip in many previous projects, and it's used on dev boards like the Terasic C5G and DE10 Nano / MiSTer.The main challenge with the camera modules is that they apparently have a fixed pixel clock output of 66 MHz. Rather than having to buffer a full frame (requiring a larger FPGA and external RAM), I'm hoping to just use line buffers on the FPGA to get some image output via HDMI.What I didn't quite get at first, is how the camera manages to output 1080p with pixel clock of only 66 MHz.It should in theory be outputting one Luma sample per clock, and of course a Cb or Cr sample on every alternate clock.But that still didn't seem to be a high enough pixel clock for 1080p?And then Mr Dexter reminded me that it's 1080p at a max of 30 FPS. lolSo yep, the usual pixel clock for 1080p 60Hz via HDMI is 148.5 MHz, and 30Hz (or 1080i@60hz) would only be around 74.25 MHz.Plus, I don't think the datasheet for the cam includes the blanking intervals in that spec, so 66 MHz should be plenty of bandwidth for the active pixels / lines.In summary - a full framebuffer hopefully won't be required for generating the HDMI output, and making the most of the cam module, but we'll see.P.S. ElectronAsh == OzOne.

author: OzOnE
author_rank: Regular Contributor
timestamp: October 30, 2019, 01:44:53 pm
content: btw, the PCB will be 2-layer for now.tbh, 4-layer PCBs don't cost a huge amount more these days, but I don't think it's really necessary for this board. Although, it would probably have made the routing a fair bit easier. lol(I prefer to use Eagle for the small-ish projects, as I'm still learning to use things like the library editor on Altium. I've been using Eagle for about ten years now, and just find it a lot quicker to get projects started on. For anything more complex, like multi-layer boards, I can import Eagle projects into Altium quite easily. Altium is a lot nicer for routing multi-layer stuff.)I have done some estimates on the power dissipation of the voltage regs on the cam board, but will be adding some copper pours to act as heatsinks on some of them.I'm running all three voltage regs (3V3, then 2V8 + 4V0 for the cam) from the 5V input atm.As Mr Dexter said in a previous post, the cam is said to draw around 450ma (for the motors) on the 4V rail, and 270ma on the 2V8 rail.I don't expect the FPGA and HDMI chip to draw much more than around 150mA from the 3V3 reg.Realising that there wouldn't be much of a voltage drop from 5V to 4V (for the cam motor supply), I changed from using the LM1117 to the TLV75801, which has a low-dropout of only around 130mA...https://www.ti.com/store/ti/en/p/product/?p=TLV75801PDBVRAll three regs will be in a SOT-223 package.If anyone could help calculate the rough power dissipation for those (all with a 5V input), that would help a lot, since I struggle a bit with that stuff.I can add copper pours on both the top and bottom layers for the three regs, with some connecting vias around the "tabs".I think it'll be OK with a bit of copper added for heatsinking. Failing that, it is essentially just a test board atm, so we could stick on some small heatsinks if need be.

author: OzOnE
author_rank: Regular Contributor
timestamp: October 30, 2019, 01:53:26 pm
content: There is one bit of "feature creep" added...The MIPI standard is becoming more and more popular on most mobile phone screens now, but it's also of course used on the CSI socket on the Rasp Pi.I don't know if it will work out yet, but I added the footprint for a 15-pin 0.5mm FPC to the "underside" of the board, so it can be connected directly to the MIPI CSI cam port on the Pi.My main reference material for this was Mike's superb video series on MIPI..So yeah, it was just something fairly quick to add to the board. If it doesn't work, then it was worth a try.But if it does work, it could turn the cam module into a nice little camcorder or wifi cam, with a Pi Zero W hooked up.There's also a PCM1808 ADC chip on the board, so we can get some audio routed through to the HDMI port.If I get chance, I might add a 3.5mm socket for line-level audio.Should be simple enough to tweak the design later by adding electret or MEMs mics.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 03, 2019, 01:02:57 pm
content: I ordered ten of the PCBs via PCBway last night, plus a stencil for solder paste.(mainly for the tiny Panasonic connector for the cam.)This will be my first time using solder paste at home, so it could get interesting. lolI'll probably just manually solder the other parts. Once the FPGA and HDMI chips are soldered, the rest is straighforward.When I first uploaded the Gerbers, I chose 5/5 width/spacing, as I thought I had quite a few areas where the spacing was below 6 mil.But there were only about five traces on the other design (Atari ST VGA/HDMI board) which needed to be tweaked.The cam board was already fine with 6/6 mil, so it worked out quite a bit cheaper.For ten PCBs (for each design), it was only $6.With the original 5/5 spacing, it was $32, so quite a big difference in cost.(the minimum trace width on the whole board is 6 mil, but the clearance between the traces and ground pours was only 5 mil in some places. I just had to change the DRC settings, then hit the Ratsnest button again to fix it.)In my haste to get the boards ordered, I did forget to add some vias and copper pours for the regulators.Hopefully it won't be too bad on the dissipation, or may require small heatsinks on one or two of them.Not much of a voltage drop from the 5V input anyway.

author: Mjolinor
author_rank: Frequent Contributor
timestamp: November 05, 2019, 02:08:36 pm
content: If it will help I have a reflow oven not doing owt that I can lend out but it will have to be picked up and brought back. I am not posting it so it needs to be someone close-ish to Burnley.It is one of these:https://www.instructables.com/id/T962A-SMD-Reflow-Oven-FixHack/

author: OzOnE
author_rank: Regular Contributor
timestamp: November 08, 2019, 12:53:18 am
content: Thanks. Much appreciated.I'll see if I can give it a go with some solder paste first, as I've ordered a stencil for the board.I can solder the rest of the components manually, but I have a feeling the tiny connector might be tricky.The pitch is so fine, I imagine the stencil will just run lines of solder paste across the pads anyway, so I'll try with the hot air station.The PCBs have just been shipped, and the parts arrived from Mouser yesterday.I'll keep this thread updated on progress.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 11, 2019, 04:50:07 pm
content: PCBs and stencil arrived...I'm surprised that they were still able to cut the tiny holes in the stencil for the camera connector.Now I need to buy some solder paste. Might as well try doing the whole board using the stencil, too.Still no reflow oven working, so I'll probably just use the stencil for the connector using the hot air station, then manually solder the rest.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 12, 2019, 11:06:29 pm
content: I'm using the 10M08SAE144 at the moment.This is the first time I've used a MAX10 chip on a project. I'd previously used the Cyclone III on most, but somebody recommended the MAX10 as it does have a few advantages.eg. It doesn't require external flash for config, and can run on a single supply rail.It also has a few gotchas, though. Like, if you buy the cheaper "SCE" version, then it doesn't have internal flash, and can't do on-chip memory initialization from the bitstream, which is kind of important for many projects.The cheaper SCE chip is around £14 on Mouser, and the SCA is £17.I realise that some of the UI and control stuff can be a bit trickier to do in Verilog, so it will either use a "soft core" CPU on the FPGA, or I've added a header for SPI, to allow an ESP32 or similar to be hooked up.I already have some Verilog and C code for an OSD that I wrote, so I'll be able to use part of that for the cam...The solder paste is on its way, and I'm feeling a bit more confident now about using the stencil, for some reason.It's something I should have started using a LONG time ago, tbh.Now that I have some of those resistor and cap sample books, it will make things a lot easier to just use stencil and paste on more projects.Hopefully getting video out of the camera and through HDMI won't be too much of a problem, as long as the camera outputs standard sync timings.I can then just route the syncs to the ADV7513, add a bit of Verilog to init the ADV and cam via I2C, then probably use a line buffer for converting to the standard 1080p pixel clock.(74.25 MHz for 30 Hz, up from the camera's 66 MHz.)Fingers crossed I don't screw up the soldering of the tiny connector, as I only bought two of them. lol

author: dexters_lab
author_rank: Unknown
timestamp: November 13, 2019, 11:03:29 am
content: Looks great Ash, looking forward to seeing the board built and some video coming out of it!!

author: OzOnE
author_rank: Regular Contributor
timestamp: November 16, 2019, 01:17:15 am
content: Finally took the plunge, and soldered the tiny connector.I realise I'll have to solder the rest of the parts on the top side with the connector on the underside (making it tricky to protect the connector), but I had to give it a try first, in case I screwed it up.It actually wasn't too bad at all, and I'm now discovering what many others have before me - modern solder paste is basically magic.Had a few minor solder bridges, but all but one of them was on the shared power pins. I expected that anyway, as I was using the hot air station (cheapo Aoyue 852, set to 300C) and not pre-heating the whole PCB.Lining up the stencil wasn't too bad. Just need to make sure to have a bit of tape ready on the top edge of the stencil.The hardest part was lining up the connector before carefully placing it down. I did also very lightly press it into the solder paste a bit, as it seemed to be sat quite high. (again, no PCB preheating, so I wasn't sure if it would settle into the paste properly).I'll see what I can get soldered on the top side tonight, and I might try using the stencil for that, too.The connctors have a satisfying "click" to them when the cam module is plugged in. Either that, or I just broke it. lol

author: OzOnE
author_rank: Regular Contributor
timestamp: November 16, 2019, 03:38:48 am
content: Right, first board soldered, using solder paste.It wasn't too bad at all, and actually kind of fun.Have to learn not to smear the paste that's already on the board, though. I'm not quite used to that yet.I'm not totally convinced the HDMI socket reflowed properly, even at 320C, because the pins don't seem to sit quite flat, even after given the connector a bit of a nudge.The rest looks fine, though, aside from one tombstoned resistor.I didn't solder the ADC yet, as I've misplaced the chips. also didn't solder the JTAG header, as I'd chosen a mill-grid connector, and forgot to order the 2mm pitch plugs. I'll have have to tack some wires onto the board instead.I did have one major oopsie, though. I'm sure you'll all be able to spot my screw-up from the photo.I also ordered the wrong package (SOT23-5) for the 4V0 reg for the cam motors, so I had to do the old "trick" of adding a diode to the ground pin of a 3V3 reg to boost the output voltage a bit.Not sure if I'm a MELF fanboy or not, as they tend to ping off the tweezers easily. lol

author: OzOnE
author_rank: Regular Contributor
timestamp: November 16, 2019, 03:52:06 am
content: Just checked the voltages, and they were all fine.The 4V0 output was a tad high at 4.3V, but that wasn't under load.So I plugged the cam module in, and could hear the motors all working and finding their index points etc.With the cam plugged in, the motor supply went down to 4.1V, so that's all fine.I'd been putting off using solder paste and stencil for so many years, and I think I can finally cross it off the list.Obviously I still need some practice, but it wasn't half as painful as I thought it would be.Hooking up the wires for the USB Blaster now.Nearly 4am, though, so I doubt I'll get any video stuff working tonight, but good progress.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 17, 2019, 09:23:50 pm
content: After about three days of messing around trying to get some HDMI output working, I finally realised what the problem was...You can guess from the photos what I forgot to do. lolI'd done almost the exact same thing on a previous project with HDMI, so I should have been paying more attention.The thing is, the ADV7513 wasn't outputting anything at all on its TMDS pins, even with all of the display detection and HPD/PD stuff bypassed via I2C, so I was thinking it was a supply ripple or soldering problem.So it seems that if the chip doesn't detect a display, it disables the output drivers regardless of the I2C settings.I managed to confirm that the ADV regs were being written correctly by hooking up an ESP32 module, so I knew the ADV chip was alive.I also replaced the ADV chip earlier, just in case it got zapped during the unfortunate regulator pinout incident.The last screenshot is just where I'm using the sync and DE signal from the test pattern generator (set to 720p), then feeding the Luma from the cam to the HDMI chip.It's quite an uninspiring image right now, but I can see the brightness changing etc. when I wave my hand in front of the cam.Next thing to try is to route the syncs from the cam directly to the HDMI chip, just to see if it will work at all with a pixel clock of 66 MHz.I'll likely need to generate the DE signal, too.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 17, 2019, 09:57:18 pm
content: First image, albeit B&W, using a very crude line buffer.Using 30% of the logic on the FPGA already, and 50% of the on-chip RAM, but that's with SignalTap enabled.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 18, 2019, 12:47:51 am
content: OK, starting to get somewhere with the I2C stuff for the cam.The protocol itself has a few quirks, as it has an "ALT" bit, which needs to be toggled on alternate I2C packets.It's definitely a task better suited to begin coded in C rather than trying to implement it in Verilog, so I have the ESP32 hooked up to the cam I2C bus atm.(as it happens, the I2C address of the ADV7513 and the camera are both 0x72 by default. Good job I put them on separate busses. lol)The command packet is fixed at a length of 44 bytes, which makes things easier.I'll write a C function to store all of the command bytes before sending, which will also toggle the ALT bit, and calculate the checksum.I *think* I may have changed the output res to 720p 30 Hz now, and the cam seems to store the setting in NVRAM.I routed the Y,Cb,Cr output to R/G/B for a quick test, and kind of see some colour now.Not sure what to do with the rest of the PCBs yet.I guess I should just send off for some more, to fix the issue with the TPD chip and the voltage regs.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 18, 2019, 02:53:26 am
content: I have the basic packet sending functions done now, but still no reaction from the cam as yet.Apparently every packet should be 44 bytes, but the various commands have a different number of parameter bytes, so I imagine the rest should just be padded with zeroes.I tried sending a shorter number of bytes for the zoom command, and although it seemed to send OK and receive an ACK, the camera still didn't respond.(on every alternate command, I get a NACK error anyway, as I haven't fixed the ALT bit thing yet.)There are a LOT of commands to figure out, and maybe the zoom needs to be unlocked before it will work?My Rigol DS1102E also doesn't have I2C decoding, which makes debugging tricky.SignalTap isn't always ideal for decoding this kind of thing, unless you write some logic to help with it.I think the camera probably is accepting the command packet now, but I need to find a command that makes it react in some way, perhaps a reset command.

author: dexters_lab
author_rank: Unknown
timestamp: November 18, 2019, 07:41:44 am
content: awesome work Ash!I don't think you need start thinking about any board revisions until we hear from the others that have these cameras about any future changes/featuresMy gut says the i2C could be handled as RS232 -> I2C, meaning any config/UI could be written easily on a PC.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 18, 2019, 08:45:43 am
content: Would be good to see if the MIPI thing works out before then, too.I was just thinking that I'd hate to have to do that mod again if I build a second one. I was going to send the other one to you. lolFor the cost of a few more PCBs, it might be worth it.PC control will definitely be a feature later on, but as soon as I can get the first I2C commands working, I can hook it up to my OSD.I'd like to have most of the features available for zoom/macro, manual focus, shutter speed etc.I think these modules will make for a neat little DIY camcorder, especially if the Rasp Pi idea works out.I'll hook up the Logic Analyser later, as the commands still aren't quite working. I suspect I may be calculating the checksum wrong.I can't tell if there's an issue with the way the ESP32 is attempting to read back the response data, though.It's supposed to do an ACK in between each byte, but I guess that's part of the I2C spec in most cases anyway.So far, the only "data" I've read back is 0x00 0x01, then the rest are zeroes.That 0x01 could be the error code, which is saying the checksum isn't right.The datasheet (I2C) says that the checksum is just a 16-bit value, and is calculated like this...checksum = 0xFFFF - <Sum of all of the bytes in the packet>(obviously not including the checksum bytes themselves.)It also says that any overflow while adding is ignored.I imagine that means you have to add all of the values of the bytes first, and let it overflow a 16-bit accumulator, then subtract the final value from 0xFFFF.I'm doing that already, but it's possible it's still wrong. It could simply be that when it overflows, the 16-bit acc value actually wraps?What I will could try next is just to loop through all of the checksum values with a short delay, to see if the camera reacts.

author: CJay
author_rank: Super Contributor
timestamp: November 18, 2019, 09:18:10 am
content: Would be very interested in one of those boards Ash, even if the protocol for the PE1005 isn't complete yet, I'm starting to experiment with FPGA and something that's 'ready to go' with all the HDMI stuff on board would be interesting.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 18, 2019, 11:14:14 pm
content: CJayI would happily send you a couple of PCBs and the assembly layout, but the problem is those missing traces on the TPD chip.I'll have to send off for more PCBs soon, with those fixes done.I finally hooked up the Logic Analyser to the cam / ESP32, and can see now that the ESP32 Arduino library does still in fact have a buffer limit of 32 bytes (not including the address byte). sighI was reading up on that issue last night, but I couldn't really tell on the Rigol o'scope, since it's capture buffer is too small.Not sure how to solve this yet, unless I can find an option in the Arduino source to increase the buffer size.The problem is, I can't just split the packet then do another Wire.beginTransmission, because that will send the I2C address again, and screw up the data.Really annoying that this limit of 32 bytes isn't made very obvious on the Arduino site.I think it applies to many of the AVR chips, too.It also makes sense now why the cam just keeps returning a packet with the RETRY bit set, because it never sees the last 12 bytes of the packet, nor the checksum.When it reaches the 32nd byte, the Arduino library is doing another I2C START, so the Logic Analyser interprets that as an address write.It's also getting a NACK back, because no device exists at address 0x00, but the Arduino library doesn't give an error for this either, since it has overrun 32-byte buffer.Anyway, at least I can properly debug things now.I'm using the Sigrok LWLA1034, which I paid around £55 for on AliExpress about four years ago.I don't think they sell them any more, which is a huge shame, as it's a great LA for the money.https://sigrok.org/wiki/Sysclk_LWLA1034I'll try to send off for a few more PCBs soon, as I don't fancy soldering those strands of wire again, especially since I already have the nice stencil made.Only other thing is to fix the pinout of the voltage regs, and add a few more vias around the ground tabs.The regs are only getting warm-ish, so there's no problem with the dissipation, luckily.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 18, 2019, 11:22:20 pm
content: I tried changing the buffer length in twi.h and wire.h to 64, but that was for the AVR chips.(on the off-chance that the ESP32 might be using those parameters.)It turns out that the ESP32 Wire library already has an I2C buffer length of 128, so I have no idea why it's not working for 44 bytes.More Googling required, I think.

author: OzOnE
author_rank: Regular Contributor
timestamp: November 18, 2019, 11:48:25 pm
content: Tried updating the ESP32 core using get.exe in Documents\Arduino\hardware\espressif\esp32\tools, but no joy.In the newer core on github, it has that define for a 128-byte buffer, but it looks like it's still being clamped to 32 bytes in the code itself.I'll try changing those values to 64, and see if it works. Worth a shot.(probably need to close then re-open the Arduino IDE first. I'm not even sure if it will definitely compile all of the source files each time.)

author: OzOnE
author_rank: Regular Contributor
timestamp: November 19, 2019, 12:10:35 am
content: Finally sending all 44 bytes (plus the address) to the cam, and the Wire library is now saying Success on each try.I had to update the ESP32 library manually...http://wei48221.blogspot.com/2018/04/arduino-esp32-how-to-update-to-latest.htmlThen I was seeing the first response byte as 0x03, which is RAE (Recovered ALT Bit Error).So you have to set the SR bit on the very first command, to reset the whole protocol state on the cam, which also copies the current ALT bit from packet byte 0 (sent from the ESP) into the cam.The cam should then toggle the ALT bit on each successive command. The ESP should read back that bit, invert it, then write it on the next command. Sheesh.Talk about going overboard on the error correction. lolI mean, it already has a checksum, and refuses any packets with fewer than 44 data bytes, so it seems a bit excessive to have that whole ALT bit mechanism too.Anywho, I can FINALLY read back the serial number from the cam.Now going to try the zoom command again. It's possible the camera is in the IDLE state at power-on. Setting it to DVC (Digital Video Cam) or DSC (Digital Stills Cam) mode requires configuring the interrupt type, sending a "Mode Change" request command, then triggering an Interrupt.I think if the cam was already in the IDLE mode, though, it wouldn't be outputting video at all yet, so fingers crossed.EDIT: Awesome - It ZOOOOMED! lol

author: OzOnE
author_rank: Regular Contributor
timestamp: November 19, 2019, 02:36:48 am
content: YCbCr to RGB on the FPGA is almost working now.The image isn't aligned properly, and will have some glitches, since it's not in sync with the HDMI test pattern gen yet.(it positions the image randomly each time the FPGA is configured, and then it very slowly creeps up the screen. The test pattern gen is driven from the camera's 66 MHz clock using a PLL, so the clocks are kind of in sync, but not Hsync / Vsync.)For some reason, the usual Green output from the YCbCr block isn't working right yet, it's constantly maxed out.You can see the colour fringing on the first image where I'm using the Luma signal direct from the camera for the Green output.The Cb and Cr signals have a slight delay from the MAC (Multiply Accumulator) operation.On the second image, I've delayed the Green data by one pixel clock. Still not quite perfect, but this will all get sorted eventually.This is 720p@30Hz, but you can see the aspect ratio isn't quite right either, due to the different pixel clocks and crude line buffer.Even then, the overall image quality looks very nice already.Please keep in mind this is not a direct HDMI capture either. I'm using analog Component from the tvONE scaler box to an Avermedia H727 capture card. Long story. lolAnd yes, the camera is upside-down atm.The first image was as-is, but with the Rasp Pi box upside-down. The second image was flipped in Paint Shop Pro, as I haven't got the vertical flip option working on the camera itself yet.I've added some more timeout stuff to the ESP32 code, which seems to be working OK now.I want to add my OSD block next.Maybe the final version of the PCB could have the ESP32 module already on it, which would allow for very fast boot times.It could also be used to control the camera from a simple web page.I don't think it would be trivial to try streaming the video itself via the ESP32 as well, unless the FPGA can be made to output the video data in the same format as the OV2640 perhaps...https://randomnerdtutorials.com/esp32-cam-video-streaming-face-recognition-arduino-ide/The "MIPI" connector on this cam board only has nine FPGA IO pins available, but that might be just enough for bt.656 style video (8 bits, plus the clock).Here's the current Arduino code if anyone finds it useful...https://mega.nz/#!v8JHiQTS!Di-HcoJxq6NW58v9Fns0MAcfSaoBNZjyOY1GwszaF1U

author: OzOnE
author_rank: Regular Contributor
timestamp: November 19, 2019, 02:52:20 am
content: Wow. The macro on this thing is insane.These boards were only about 12mm from the lens, and the Auto Focus worked no problem.

author: Yansi
author_rank: Super Contributor
timestamp: November 19, 2019, 10:27:40 am
content: I am starting to think I should get a cam or two too, as the support HW for it seems to be quite simple, I expected much much more trouble with this.Would be probably quite good motivator for me to improve my VHDL skills.Are any cams still available?

author: OzOnE
author_rank: Regular Contributor
timestamp: November 19, 2019, 03:55:59 pm
content: Took quite a while to get the OSD working, mainly because of the differences with the Arduino SPI functions on the ESP32 tripping me up.I was also being very lazy initially, and not soldering a specific ground wire for SPI, instead relying on the one ground wire already in use for I2C.Of course.. ground bounce caused glitches on the SPI SS_N signal, and screwed everything up.My OSD code basically allows you to embed graphics tiles within the text lines. (4BPP, same as the Genesis/MD)I do need to change that Sonic graphic, though, as it's been like that since about 2013. lolObviously the OSD window is very small right now, but it can be resized quite easily, and positioned anywhere on the screen.The next thing I want to do is to hook up a small joystick module or a few buttons, so I can control the zoom and focus directly, or via the OSD.I'm trying not to add too much feature creep, as it's getting relatively complex already.The camera I2C functions are working quite reliably now.I added a timeout / retry for the response data, fixed the response check itself, and also now doing a checksum on the response, to see if it matches what is expected.I can also change the video output format, but it looks like it requires an interrupt pulse before the change takes effect.That doesn't seem to be mentioned specifically in the manual, but I could be missing something.It's working better at 720p@60Hz atm. It's a better match to the 720p pattern gen, but still not properly synched.So every time I configure the FPGA, the whole image rolls vertically. But, the image does at least stay put afterwards.Looks like 1080p is having trouble with my bodge wires, which was fully expected.The image probably isn't supposed to have that "Matrix" style green tint to it, but I'm still using the Luma channel for "Green" atm.I don't quite get how Luma is working so well for green, as it would surely contain brighter areas for the red and blue content?Maybe that's why the image looks a tiny bit washed out?The OSD logic alone is taking up around half of the FPGA, but there are definitely some savings to be made there.(it has a way of displaying a much larger image which can scroll a tile map, like a game does. I'll probably remove that.)SignalTap is taking up about a 5th of the logic, too.In total, I'm using 80% of the FPGA.

author: dexters_lab
author_rank: Unknown
timestamp: November 19, 2019, 10:28:16 pm
content: Quote from: CJay on November 19, 2019, 05:42:02 pmi don't think it would work, the output from the camera is not bt.601, it's a fixed output clock and a separate h & v sync signal with no SAV/EAV codes in the data so it's a bit more raw than 601/656I would like a 601 compliant output TBH so i can get HD-SDI, i figured i'd let Ash get video output with HDMI first before i start pestering himThe other issue with HD-SDI is all the 656 to HD-SDI serialisers seem to be crazy expensive or are tiny BGA devices that are hard to work with

author: Yansi
author_rank: Super Contributor
timestamp: November 19, 2019, 11:12:46 pm
content: Why not encode and serialize the SDI directly in the FPGA and use just a cable driver after that?//EDIT: First google result for a HD-SDI serializer + driver: LMH0340 (and less capable derivates). Nice package, but fuuuuuuuuck the price. (but bearable price from the wild east)

author: OzOnE
author_rank: Regular Contributor
timestamp: November 19, 2019, 11:28:52 pm
content: @Cjay - Yep, the ADV7513 accepts YCbCr as well, but as Mr Dexter said, the camera doesn't use a bt.601 / bt.656 style interface.The ADV7171 also only has an 8-bit wide input bus, whereas the camera outputs 16-bit.You could maybe feed the separate H/V syncs to the chip, but you'd still need a small CPLD to combine the Luma and Chroma samples first.In theory, that would also get around the need to convert the pixel clock, as the ADV7151 would just output analog video.@Yansi - We gave a fair bit of thought to adding SDI to the board, and I still might try that by encoding it on the FPGA itself.I have some code from when we were trying that before, but I don't have any SDI stuff here to actually test it.For very short cable runs, it might even work OK with just a cap for AC-coupling, but obviously a proper cable driver chip would be more ideal.And yeah. The prices of the full SDI serializer chips is pretty steep. lol

author: OzOnE
author_rank: Regular Contributor
timestamp: November 20, 2019, 03:23:41 pm
content: oic, I just glanced at the block diagram the other day, and only saw the "P7-P0" part. lolSo yeah, if it can handle Luma on bits 7:0, and interleaved Chroma on 15:8, then it might work OK.

author: Yansi
author_rank: Super Contributor
timestamp: November 20, 2019, 03:55:22 pm
content: So after seeing that this can indeed be worked out to functional state quite easily*, I have finally decided to buy a camera too. Yaaay!*thought it would be much more troublesome, especially with the documentation.Now I have some motivation to start doing FPGAs (instead of just CPLDs) and do something more complex with it then just blinkenlights.

author: dexters_lab
author_rank: Unknown
timestamp: November 24, 2019, 09:16:54 am
content: Quote from: CJay on November 20, 2019, 06:46:05 amahh ok, yea looks like your right Clint, sorry!!Will have to examine the datasheet in some detail to see if it can be compatible with the output of the camera... it certainly looks pretty close

author: dexters_lab
author_rank: Unknown
timestamp: November 24, 2019, 09:21:58 am
content: Quote from: Yansi on November 19, 2019, 11:12:46 pmSpeed i think is the issue, SD-SDI is ok (270mbps) but once you make the jump to HD the output serial speed goes nuts (approx 1.5gbps)

author: Yansi
author_rank: Super Contributor
timestamp: November 24, 2019, 12:16:37 pm
content: Sure, and 3gbps for 3G-SDI.(Cyclone IV GX series should be able to do it)I have put down a bit of thought how could I approach the camera myself - and ended up with Cyclone IV FPGA. Essentially, it is the same as the MAX10 internally, but larger.I have found that I can buy Cyclone IVs from china for as low as a couple of bucks - so out of curiosity, I have ordered a bunch of cheap (up to suspiciously cheap) EP4CE6E22C8N. Very interested if or what will arrive.EP4CE6E22C8N is the smallest of them in LQFP144: 6.3kLE, 270kb ram. Comparing to the MAX10 OzOnE has used, this shall be enough.Disadvantage is, that I need at least 3 power supply voltage (Vcore, PLL, Vio) and a configuration flash (EPCS4). But it does not seem too difficult and I would make the PCB 4 layers anyway.First I'd have to make myself more familiar with VHDL (it's been years since I've touched it) and the FPGA itself, including probably the new Quartus software (I have only 13.1 installed currently). Let's hope it'll go well.//EDIT: Grammar. :-/

author: dexters_lab
author_rank: Unknown
timestamp: November 28, 2019, 10:05:37 am
content: So it seems everyone wants to do their own thing with this camera, given one of the hurdles is the connector so how about i make a passive breakout PCB that can mount on the bottom of the camera and breakout all the pins to something easier to work with like a 1.27mm pitch pin header?That way it'll make it simpler for you all to use with whatever FPGA/SDI/Video ICs you wantI should be able to get my channel sponsor to cover the costs to make the boardslet me know what you all think?

author: Yansi
author_rank: Super Contributor
timestamp: November 28, 2019, 01:12:47 pm
content: https://cz.mouser.com/datasheet/2/315/AXT%203%204-1196688.pdfI don't see anything difficult on that connector. 0.4 pitch is standard even on LQFP ICs and the pins stick out on the sides almost 0.5mm, no hidden GND pads under the connector body itself.Try soldering one of the SMD SATA connectors, or just one of these modern Samtec connectors for high speed digital, that has the GND knife in the middle, such as QTH-030-02-F-D-A.https://www.snapeda.com/parts/QTH-030-02-F-D-A/Samtec/view-part/That is what I call i difficult to solder connector.Also don't see a reason why a 60-70MHz bus shall be routed through a piece of likely impedance-inappropriate extender - or not?But I am not against that in any way! Just thinking it may not be necessary.//But maybe I won't care anyway, as I will probably not receive a camera. Seems some shipping problems, in between the seller and/or the transport company? Not sure yet.//

author: Yansi
author_rank: Super Contributor
timestamp: January 09, 2020, 09:03:34 pm
content: Any progress with evil camera hacking?I have currently only reduced free time for toying, so I am currently stuck with other stuff with higher priority, I have to finish first. Anyway...As an FPGA n00bie, this may be a bit too much to chew as a project, so please forgive me a couple of the following dumb questions. Any help welcome!1) The camera provides its video output at just 66MHz with almost no blanking intervals, but the overall frame rate and resolution fits: To convert to a standard 74.25MHz pixel clock rate, I only need to buffer a single line (two respectively): One being written with 66MHz rate, while the other will be pushed out at 74.25MHz. Is that correct?2) Camera output is only YCbCr. I still have big mess in my head and hard time understanding what the difference between all those color spaces exactly are (YUV, YPbPr, YCbCr, Y'CbCr, RGB, R'G'B', etc..), but I understand to convert between any two of these, only 3x3 matrix multiplication is required. Question is: Do I need an FPGA with a HW multiplier to be able to accomplish a color space conversion? Is it possible to build a good enough performing multipliers from the generic logic fabric? (Yes, that f!cking FPGA I'd like to use does have exactly 0 multipliers).3) As the camera outputs only 30 frames/s, is this output mode generally accepted by HDMI sinks? (TVs, monitors) I hope it is...What I was thinking about accomplishing is to provide a conventional HDMI output and also HD-SDI (1.485Gbps) output.I have researched what FPGAs are available and Altera Cyclone IV EP4CGX15BF14C8N seems to fit the best. (15k LE, 540kbit mem, 2x 2.5Gbps TRX, 72 IOs, FBGA169). I will use the EP4CE6E22C8N only in case I fail with the FBGA169 pcb design.For the HDMI transmitter, I have selected a Silicon Image (Lattice) SiI9022ACNR (165MHz 24bit QFN72, 3V3/1V8 compatible), which costs peanuts (compared to for example an AD7513).For the HD-SDI output, I'd like to use the internal serdes in the FPGA and add just an external cable driver. (Yet to decide which one, can't find any cheap enough one).I will try to squeeze the design on a 4L pcb. Hopefully the FPGA can be done on 4L.Thank you for any comments on this.

author: Yansi
author_rank: Super Contributor
timestamp: January 10, 2020, 10:25:48 pm
content: Any ideas or thoughts anyone? Or Everyone already finished toying with their cameras and projects are done?Finally decided to use Gennum GS2988 cable driver instead of Microchip EQCO30T5. Those Gennum chips seem to get even cheaper than those from Microchip. Either way, they seem to be pin compatible or sort of.

author: dexters_lab
author_rank: Unknown
timestamp: January 11, 2020, 09:15:48 am
content: Not sure where OzOnE got upto, i know he had video and I2C controli think he was toying with the idea of another pcb design but everyone's requirements seem to be differentCJay, i have your cameras here BTW

author: RoadRunner
author_rank: Frequent Contributor
timestamp: February 07, 2020, 10:42:57 pm
content: There has been quite progress from other forum members but i still felt tempted to interface this camera to USB3.0 with FX3 so here is little story of success. i have also received few camera modules from Mjolinor , but only one of them was able to survive shipping.I implemented opensource USB UVC firmware so that any application that support UVC can stream almost 1Gbps full HD 1080p video Over cypress FX3 USB 3.0.Camera output has little odd output timing which has been handled by FX3 GPIF frontend.Images attached to this message shows image quality is really nice.Complete description, PCB ,Firmware source with more description and images are available on my blog.https://www.circuitvalley.com/2020/02/diy-usb-3-1080-full-hd-camera-PE1005-auto-focus-optical-zoom-cypress-fx3-usb.html

author: dexters_lab
author_rank: Unknown
timestamp: February 08, 2020, 02:56:35 pm
content: very nice

author: PlainName
author_rank: Super Contributor
timestamp: February 08, 2020, 03:28:26 pm
content: Wow! First class job, that man

author: Yansi
author_rank: Super Contributor
timestamp: February 08, 2020, 09:57:57 pm
content: Cute! But why the gloves friend?Also, could you share some tests of the captured video output?USB3 is way past what I would attack, I think it'd be enough for me to convert to just HDMI plus a HD-SDI outptu. Another silly challenge I have added myself is to use an FPGA in a BGA package - tbh there is no way round that if one wants the gigabit TRX included.Sad part is, I am currently in some family troubles, in front of solving whether to move or not and how, then to start reconstructing the new place so it can be more usable and livable.

author: RoadRunner
author_rank: Frequent Contributor
timestamp: February 09, 2020, 03:06:35 pm
content: Quote from: Yansi on February 08, 2020, 09:57:57 pmThere was no particular reason for wearing gloves. Right before taking this video i was doing some soldering work. I generally wear gloves while soldering to save my hands from my sticky liquid rosin flux.Regards

author: Yansi
author_rank: Super Contributor
timestamp: February 09, 2020, 07:27:18 pm
content: Okay i understand why the gloves now. Was just curiois if you are not afraid of the (leaded) solder.

author: RoadRunner
author_rank: Frequent Contributor
timestamp: February 09, 2020, 08:17:19 pm
content: Quote from: Yansi on February 09, 2020, 07:27:18 pmI do not use leaded solder, Stannol tin solder works perfect for me . Though i am not afraid of lead solder but. I will still want to keep my self a km away from it.I think flux is absolutely critical, After trying out tens of different flux type i have found my self making my own liquid flux with solid activated rosin.