Diver Firmware

Let’s discuss issues and features with the current Diver firmware, and what you would like to see in a bugfix oriented firmware update soon.

On my own list of issues to investigate:

  1. Sync robustness. I have had several reports of an intermittent “blip” that occurs in the waveform at longer, but random intervals (1-2 minutes apart). I can see and confirm this issue here as well. I have a few solutions to try.

  2. Texture wrapping / scanline discontinuity. Improvement here may not be possible without a hardware deinterlacer, but there may be some things I can do to improve waveform discontinuity between lines through some more aggressive interpolation. Or I may just have some math wrong! Or it could be related to issue #1. Some investigation is needed.

Threads related to issue #2:

  1. More ramps. Easy stuff! The same library code will power these ramps as the ramps on Chromagnon and TBC2. A VCO mode and new pseudorandom/FFT modes would be in this category too, but we’ll just have to see how fast the other issues get solved.

  2. Non-standard syncs. Diver is currently an NTSC/PAL based device, using an IC that is designed for NTSC/PAL input only. This makes it potentially difficult to integrate with new HD sync generators like Chromagnon and the Gen3 encoder module. I want to see what, if any, ability the TVP5150AM1 has to detect or PLL lock to non standard timings. Since the TVP5150AM1 doesn’t actually generate the video itself, and the STM32F4 system is running on its own clock PLL, there may be some workarounds we can investigate.

  3. ADC/noise performance and “flickering” issue. It looks like we’re getting a little value jitter in the phase CV input. I need to add some better filtering to the code. This issue may be different in different case power scenarios, and I do not believe it relates to issue #1.

Threads related to issue #5:

  1. Settings permanence across power ups. I have working code for this already, using some of the internal flash as an EEPROM. So I think we can make this happen, no problem.

And that’s about it. What else? My ongoing assumption is that issue #1 is the primary concern of users with the module as it is. Please let me know if that is not the case.


Does issue #1 also refer to the sort of “seem” in the video field as well? I’m sure you’re aware of the issue I’m talking about, though, the exact way to describe it is lost on me at the moment.

1 Like

This issue, right?


not sure if hardware supports it but i would love to see Diver remember settings between power cycles. really this is the main weakness of the current firmware for me! beyond that i’m looking forward to the remaining slots getting filled up with cool stuff and/or being able to fill them up with things myself.


I hope that HD sync will be possible but really my main issues with using Diver right now are the one to two pixel seam mentioned in Sean’s post and losing my settings with every power cycle. Having the module always save settings on power down would make it less of a hassle to get back to where I was in a patch.

More ramps to fill out the banks or even the ability to add our own gradients would be lovely.

Is the oscillator mode/bank still a possibility?


Thank you all – I added a couple more items to the OP list if you want to go over it.

1 Like

yes, exactly what i was talking about

These kind of features should be easy to add, and part of item #3 in the OP. I can also open source the firmware once we are at a stable release.

Some sort of simple “ramps shader scripting” thing may be the way to go long term.


#5 still bothers me. Perhaps I’m in a minority here, but the noise problem makes keying Diver output impossible. It greatly reduces the utility of the module. That makes it easily the most frustrating module I own. It’s so bad, I’ve considered selling the module.

I don’t own a computer that can run the firmware updater. So I’ll have to buy a device that can do. It’s unlikely I’ll have any other use for that device, so I’m seeing this module in terms of the Sunk Cost Fallacy. I could spend money to make it usable or I could just sell it with a warning to the buyer. So whoever buys it can run the firmware updater.

That’s the main reason I’ve kept the module this long. It has some small value, but nowhere near enough to justify the space it occupies in a system I can’t expand. Either I sell my Diver or I sell another video module. So when the new firmware is available, that’s likely what I’ll do. The buyer will have to trust that update will work.

Of course, if I try selling it and nobody buys it, my only option will be to keep it. I could trust that the new firmware will justify purchasing a device that will run the updater, but it’ll be more sunk cost. Perhaps it’ll pay off, avoiding the fallacy part.

Obviously I’m very unhappy with all this.


Yes, I’m not quite sure I’m following you. I wasn’t under the impression anyone found the module unusable as it is – just that we have a few quirks to clean up. I’m very sorry to hear your experience with Diver has been a disappointment.

On output noise:
I don’t have keying noise in the issue list at all. Is #5 (ADC performance, phase displacement jitter) what you mean? Or are you talking about frizzy edges on the the edge of the shapes?

Frizzy key edges are very common for LZX patches, especially using hard keys and viewing the black/white output key directly – this is why we overhauled our power standards for gen3. But it’s usually something that is masked within the space of the patch, and becomes an artifact of the medium, in practice. Keying performance is also going to be related to what keyer you are using and its noise floor as well. The Visual Cortex keyer is noisier than I would like, for example. I did not see anything in the thread “Diver flickering” that was uncharacteristic for the system in terms of hard key performance in general. I did see some Phase CV ADC jitter, which is a bit different (and what I mean in #5.)

I can definitely take some quantitative noise floor measurements on the outputs and compare them to Cortex ramps, so we can see where that stands on a chart. I’m interested to know if the noisiest bits are from the ADC path or from the hardware DACs/buffers themselves. If it relates to the former, I can do more interpolating (this relates to issue #2).


What kind of computer do you own?

Yes, the fizzy edges. You can see this clearly in the first video I posted. The second video shows the keying results. This is in a system using Malekko power supplies. I don’t get fizzy edges when keying anything other than Diver on this PSU.

I mainly use Doorway for keying BTW. I didn’t get better results using the keyer on VC. I’ve tested Diver->Doorway->VC and Diver->VC. Same results: fizzy edges. The keying video I posted used Doorway, but the VC keyer test looked the same to me. Should I just accept that hard keying Diver won’t work? You can see why soft keying in the first test video wouldn’t be much help. The waveform isn’t stable! Where does that horizontal jumping come from? Its small but its clearly there. I called the problems “jitter and flickering” in the video description.

You’ve linked issue #5 to the videos I posted Feb 2020. I described keying this noisy output as impossible because I often want clean, stable keys in my patches. So perhaps I should really say it is, for me, barely usable. I can get good results from some of the banks, but only a few.

That’s why I’m hopeful that a firmware update will fix this. I’m also unhappy that it’ll require me to purchase a device to run the updater. Obviously that’s beyond your control. I’m simply in the unfortunate position of not owning a machine that runs Windows 10, which the updater requires. This is a personal issue, rather than a technical issue with the module itself. I still want to see a firmware solution. However, if it requires a hardware solution, then the updater’s platform issue will be totally irrelevant.

I hope this post is easier to understand than my last. It’s getting late here in the UK, so this should be my last post this evening. I’ll be happy to continue the dialogue another day, of course.


1 Like

Diver has a standard USB DFU protocol built in – you won’t need to purchase any type of device to run the update. You just remove the module from your system, attach a USB-A to USB Mini-B cable to the back of your Diver module, and then plug it into your computer. Being powered from USB enables the firmware update boot mode.

Generic USB-DFU driver is all that’s required. We have our own desktop app in progress for USB-DFU updates, but in the mean time you can use a generic app that is available for free. I’ll make sure to document MacOS and Windows instructions for the firmware update, when we release one.


Should I just accept that hard keying Diver won’t work?

Maybe, but let’s discuss it a bit more. I will take some measurements.

Another factor is waveshape – if you are trying to key at the very top edge of a sinusoidal ramp output for example, your noise floor increases (literally exponentially). This is why modules like shapechanger, etc use a different technique for making circles (cropping the entire ramp itself).

The right answer for the look you want may be a special ramp mode, with hard keyed outputs (rather than ramps) being sent to the outputs. I’ll let that stew.

Yes, I see it! That’s what I meant by “horizontal phase CV ADC”. That’s something I know I can clean up – the worst case is we sacrifice the modulation speed a little bit on the phase CV input.

Part of the problem is that I am seeing two separate (from the electronics perspective) issues. One is that “output noise floor is higher than expected, resulting in noiser than typical keying response”. The other is “the CV input sampling has some intermittent jitter, resulting in the whole image jumping left/right by 1 pixel at random timing, if the image is frozen in place.”

Both are valid concerns and valid issues, and I will treat them both as such – and try to find solutions for both.


This is excellent news. My earlier comments were mislead by reading a page linked to in the “Firmware Update Instructions” section of the All About Diver thread. The page linked to talked about an update utility that only runs on Windows 10. I’m very happy to learn that this is not the case.


1 Like

syncing diver via vidiot in my setup i often have to powercycle my case after the inital startup, to not get this (kinda funky) unstable output

sometimes diver then gets stuck, no lights, no power no output. i guess this is issue #1 related

#1 or#2 or #5? mirrored shapes are off center with both faders all the way down, thats what bugs me the most next to #6

more ramps would be pretty neat, vco mode sound amazing

thank you


I’m running Ubuntu on all my computers. Please see my reply to Lars on the firmware updater. Anyone like me using a system downstream from Debian can install a package called dfu-util and use that to update their Diver. I may already have the USB cables needed for the link.


1 Like

As always, your support is greatly appreciated. Thanks.

1 Like

Hi nerdaware
maybe instead of purchasing a specfic device to update a single module you could try reaching out to the community here (and modulargrid) - you never know when someone a few miles away has what you need and is willing to give you a hand - maybe meet you somewhere with a laptop for example - or a friend, colleague or family member might be willing to help
I may be in the same boat with some firmware updates - I only have Macs! but I know people who have windows boxes too and vaguely a few with linux
never hurts to ask!

EDIT - just read a bit further - you appear to be sorted with your linux computers - which is of course excellent news!


I’ve wished on multiple occasions that the scroll speed could move at a higher range. Is that a possibility?

1 Like