Thanks @csboling. From your link it looks like this is the command I should have used, with fuse settings:
avrdude -V -p m88p -c usbasp -P usb -B 1 -U flash:w:LZX-C1-SW-V1.0.elf -U efuse:w:0xF9:m -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m
I’ll try this tonight.
@transistorcat these are the fuse settings you’ve given a couple of times, but Lars’ post says FF-DF-F9 (or F9-DF-FF). Can you tell me what the difference between your settings and Lars’ is?
Good news, my Cadet 1 is now generating good-looking sync!
I will write more about what I learned soon.
TL;DR I needed to set the fuses, and avrdude was confusing things by reading back efuse as 0x01 even though it had set it correctly!
Those were the fuse settings i read from the .elf file when i ran ‘readelf LZX-C1-SW-V1.0.elf -x .fuse’
Both the ‘FF’ and the ‘CE’ will set the clock source to external, but the CE will allow for a few ms more of settling time before running.
I’m guessing either works, especially since the cadet has not just a crystal but a full oscillator.
Executive Summary: the fuses need to be programmed correctly!
Notes:
The biggest learning for me was that the .elf file is a container with various data inside it. Mostly it’s the actual flash binary, but my avrdude program couldn’t read .elf files directly, so I had to use avr-objcopy first to extract that binary image into another file.
These links were helpful:
https://helpmanual.io/help/avr-objdump/
As well as the binary the .elf file has the fuse settings in there. I used avr-objdump to dump out the entire contents of the .elf file to see what they should be set to.
When avrdude verifies the efuse values it has just written it gets back a different value. I program it as “0xff” but it gets back “0x01”. That’s apparently quite OK, which is why the -u flag is required to tell avrdude that it’s OK that it appears to have failed. This calculator was helpful: http://www.engbedded.com/fusecalc/
It says: " * Note that some numerical values refer to fuses containing undefined bits (set to ‘1’ here). Depending on the target device these fuse bits will be read either as ‘0’ or ‘1’. Verification errors will occur if the values are read back with undefined bits set to ‘0’. Everything is fine if the values read from the device are either the same as programmed, or the following values (undefined set to ‘0’): Extended: 0x01 ."
Also, I had the programmer plugged in backwards the first few times (doh!)
If you can use a GUI program instead of the command line I suspect things will be much easier and you won’t need to know all that stuff above, but sadly I don’t have a computer that I could install one on to.
Also note that you can program the fuses and flash separately, one at a time, with multiple calls to avrdude. That was helpful as I could see that hfuse and lfuse were successful, then work on efuse and the flash image separately until I got them to work.
Here are some command lines I used.
Change into the avrdude program folder:
cd /Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/
I copied the LZX elf image file into that same folder, for convenience.
Dump the .elf file contents to see the fuse values:
./avr-objdump -s LZX-C1-SW-V1.0.elf
Extract the flash image into a separate file:
./avr-objcopy LZX-C1-SW-V1.0.elf -O binary LZX-C1-SW-V1.0.bin -j .text
Flash only:
./avrdude -c usbasp -p m88 -P usb -B 1 -U flash:w:LZX-C1-SW-V1.0.bin -C …/etc/avrdude.conf
Fuses:
./avrdude -c usbasp -p m88 -P usb -B 1 -U lfuse:w:0xFF:m -U hfuse:w:0xDF:m -U efuse:w:0xF9:m -u -C …/etc/avrdude.conf
Just the efuse on its own:
./avrdude -c usbasp -p m88 -P usb -B 1 -U efuse:w:0xF9:m -u -C …/etc/avrdude.conf
This shows the fuses being programmed, along with the efuse verification error which you can safely ignore:
avrdude: set SCK frequency to 750000 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e930a
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xDF"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDF:
avrdude: load data hfuse data from input file 0xDF:
avrdude: input file 0xDF contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xF9"
avrdude: writing efuse (1 bytes):
Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.03s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xF9:
avrdude: load data efuse data from input file 0xF9:
avrdude: input file 0xF9 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x01 != 0xf9
avrdude: verification error; content mismatch
avrdude done. Thank you.
Thank you to everyone who helped, particularly transistorcat and csboling.
Hi all, built this a while and can’t seem to figure out my issue. I’m doing cctv camera -> Cadet I input// cadet I output -> cadet III input /// then if I take the rca output from cadet III into my video capture it looks ok (just as if I plug my camera direct into cadet III and take the video straight out). But if I take the luma out into Cadet II I get a horizontally scrolling image on any input (I have the 14 pin cable connected).
If I take the horizontal or vertical syncs from the cadet I out into a function generator (Maths in this case) and then back into one of the RGB encoder inputs I do get horizontal lines so the sync generator is doing something…
Anything I can measure (voltages on the atmega) to tell if I need to flash the chip or any other ideas? I can post pics if that helps but I think it’s a clean build. Thanks!!
Hi Adam,
The ‘video out’ on the Cadet III video input is actually just a buffered copy of the video input, so it’s almost always going to work just fine (the same is true of the video output socket on the Cadet I sync generator).
However, if you use the luma output of the Cadet III video input and put it into a Cadet II encoder which isn’t properly synchronised to the input signal of the Cadet III (by the Cadet I sync generator) then you’ll get exactly the behaviour you’re describing. Basically the Cadet I is generating a clock which the Cadet II is using, but it’s not quite in sync with the Cadet III input, so the two tend to drift slightly on the screen compared to each other.
You can use a scope to see if there’s a sync signal on the 14 pin connector, which there almost certainly is you’re actually seeing output from the Cadet II encoder. With no sync the encoder doesn’t produce any output signal at all. But unfortunately I don’t think there’s any simple way to tell if the atmega is following the external video input or generating it’s own internal sync, other than implicitly by looking for the out-of-sync behaviour you’re seeing.
My suggestion is to try a few different input sources, and see if you can find one that works correctly. For what it’s worth (keeping in mind I use PAL exclusively) I’ve found that my Cadet I encoders occasionally struggle with some signals (especially those from VCRs) but it’s often not predictable which ones it won’t like. I’ve often found that putting the input signal through a scaler, TBC, video mixer, or even a just distribution amplifier before the Cadet I input can help it to sync better.
Thanks for the reply, aladan! Ah, that is a bit of a bummer. I don’t have much video gear at all but I think I tried every combo between my Cadet I-III, Syntonie CVB module, and Reverse Landfill triple function generator and don’t get a proper sync’ed signal when running through the cadets (side scrolling and it also appears in triplicate spaced apart horiztally). If I run signal into Cadet I and RCA out of Cadet III into the CVB and into Cadet II encoder I was getting a sync’ed signal but that was with the sync ribbon cable disconnected (because, as I understand it, the CVB does not require syncing), which sounds like further proof that the Cadet I is working, just not in the way I’d hope 
I have a VCR that is a little tricky to get in the same room as my modular but I’ll give that a go - though I vaguely remember having the same issue a few months back when I tried that. Maybe I’ll look into an hdmi to composite converter just to try something else.
I’m running the modules off a tiptop uzeus and have some cheap RCA cables - could either of those things possibly be contributing to the sync issues?
Can you tell us about your CCTV camera? What resolution does it output?
I honestly have no idea. I bought it for nothing off a guy in town who does editing and has a video store (!) - it’s used or older, and the only label on it says “B/W CCTV Camera”, the lens is Computar 8.5mm 1:1.3 (my apologies for very obviously knowing very little about this stuff). It runs on 24v and now that I’m looking at it it has a trimmer labeled “line phase” which I have not messed with.
Make sure you set the PAL/NTSC switches correctly for that camera.
Might be worth trying to hook up with another video enthusiast in your area to see if they can help out with more gear to help debug, if you can?
I don’t think cheap RCA cables would cause the problem, but I guess it’s possible. I don’t know anything about the power supply you mention, sorry.
Thanks again. I did try with both NTSC and PAL switches on the cadets just for the heck of it.
Will look into an alternative video source to try out.
Edit to add: I tried the vcr/dvd player and all seems to be working. Good news, but a little embarrassing I didn’t try that before posting 
Ahhh, I have been told that DVD players generally have a decent quality output so they are good for testing with
Yeah this was just a very cheap, very used dvd/vcr combo unit. I tried connecting the security camera to the video input on the vcr side but without the remote I’m not sure there was a way to switch to the vcr input (and no universal remotes in the house). Still curious if that would work. Anyway, here’s a still of my production of Neubauten Under the Sea!
