PM’d! Looks great! =)
Nice work! Great form factor, and very handy.
What SMD component sizes are you using? 1210?
Got mine today- thanks Picard. Initial thoughts- smaller than I expected which is cool!
Hooked it up to an MPK mini to control a Shruthi, all good, I’m not noticing any latency on the keys side. There were a couple of times when really abusing the knobs that it seemed a little “steppy” in terms of the resolution of the cc data it was sending out, but I need to do some more thorough testing, it may have just been the patch. Like @shiftr says, having 2 USB ports is a nice feature.
@elthorno MIDI CCs only have 128 steps, so that may be the reason you noticed steppiness- a limitation of MIDI, rather than of the box itself.
@toneburst I should have explained it a bit better; it was more like some intermediate values were getting skipped out if I went really fast with the filter cutoff, I am used to the stepping but this seemed a little different.
as I said above, if the sum of the incoming USB MIDI message rates of both ports exceeds the MIDI DIN speed, some messages could be skipped if this condition holds and the internal buffer of 1024 bytes overruns.
But this should only occur if you simultaneously move all knobs very fast - and then you are out of specification…
Arrived safely. Appears to be working fine with no discernible latency. I’m using it with a very cheap usb keyboard which is probably not class compliant with no problems.
Thanks for doing a great job on this
The first community benefit did happen!
@larsen discovered a problem interfacing his controller. We discussed it. He found a resolution and he updated the firmware by himself! Great work, Sir!
It also will run in the “official” firmware line. DIY community at it’s best!
I’m happy to help! This was fun! =) And thanks to you too for your great support!
For the record, the troublesome controller was an M-Audio Keystation Mini32.
What was the issue?
Perhaps @picard can explain it better but if I understood it correctly other controllers usually send USB messages ended (or padded) with zeroes, but this one doesn’t. The code did not handle this, which lead to old messages being left in the transfer buffer.
I’ve build up my “Pure” board, and I have the VNC2 Debug Module ready to load the firmware…
After loading drivers and the VNC2 IDE (2.0.2), I cannot see the VNC2 Debug Module either from the IDE or VinPrg -a
I get "No debugger interfaces"
Windows Device Manager shows the COM port “USB Serial Port COM5” and the “USB Serial Converter” as installed OK with the FTDI drivers.
I’m using Windows 8.1 64-bit. I also tried this with Windows 7 32-bit. Same story.
Any thoughts from anyone that has seen the VNC2 loader/debugger working?
Should I be able to see the VNC2 Debug Module in the IDE even with it disconnected from the USBPal board?
Glad to hear you managed it so far. Now let’s finish!
I think the target system needs to be attached to the debug module to find it in the IDE.
So I plug the USBpal board (only) to the debug module and then the debug to the PC.
(the windows device manager shows a “USB serial converter” in the USB-controller tree and a “USB serial port” in the connectors.)
Then the IDE can connect the board in the “Debug” tab showing the target MCU (VNC2 32-pin) like this:
Thanks for the quick response and the pictures, Picard!
OK, I’m seeing all the same connections and power LED + yellow LED on the debug module.
So it sounds like the USBpal board does need to be connected for anything to show in the IDE (since your screenshot is showing the IC on the USBpal board). perhaps I have a board issue, not a programmer configuration issue.
- I will recheck/reflow everything.
I must admit, I wasn’t sure about the values for the 4 inductors (perhaps you can confirm), and I think my crystal is 13Mhz instead of 12 (not sure how I mis-ordered that one!).
I’m pretty sure that 13MHz won’t work.