The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I'm in the middle stages of getting a GoBus module put together for one MIDI input and 3 MIDI outputs.
The intent is for this to be a great board for creating your own MIDI controllers, arpeggiators, sequencers, and interfaces.
I don't have any code for this written (I've written both native and managed MIDI libraries in the past, however, including one for .NET Gadgeteer, so I have quite a bit of experience there), but I expect to have at least the following features:
Splitting/Routing MIDI in to Any of the outs based on different rules (message type, channel, etc.). This includes soft-thru without the messages having to be processed by your C#/VB code.
Generating a 24ppqn clock pulse on the CLK corresponding to incoming MIDI clock messages (this is useful for some other modules I'm working on).
Automatic responding to active sense messages from within module code (you can switch this on/off)
On-module filtering by different rules (message type, channel, etc.). This is especially helpful to avoid spamming the relatively slow NETMF side with clock messages or, if you don't want them, pitch bend and other continuous controller stuff.
A message-based API for NETMF allowing you to respond to incoming messages from MIDI.IN.1
A message-based API for NETMF allowing you to send messages out through any combination of MIDI.OUT ports
Automatic message assembly on-module before they are sent to your code. This greatly simplifies the NETMF code as it doesn't have to worry about interrupted or partial messages.
In general, all the time-critical functions and filtering happen in native code on the module, and rather than expose virtualized UARTs, I'm going with the stream protocol. This will help eliminate the lag issues I had with my other MIDI module.
Attached is the current layout. I had it ready to send to production until Chris talked me into putting a crystal on board, and dealing with startup power, so now it's a mess and isn't properly routed. You get the idea, though.
Here's the image from yesterday, routed, without crystal. U2 is a new component I'm testing to replace 6n138 opto isolation for MIDI. It's much smaller and much faster. It's typically used for USB isolation, as I understand it. If it doesn't work, I'll go with a 6n138/6n137, despite their large DIP-8 size.
I don't have a release date or pricing for this board yet. It's the first of a group of related modules which could be used together to produce some pretty cool music-related devices.
On-board processor is a STM32F205, plenty powerful enough for quite a bit of on-module processing.
I'm trying to wrap up the board this week so I can send it off for prototype manufacturing before I head to India on the 15th. If you have requests related to this board (or other related modules), let me know.
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Wow Pete, this is a really advanced and powerful board!
It could be used for all kinds of things. Are you aiming for home automation or music primarily?
I agree, the 6n138 typically used for MIDI are really big. I guess optocouplers need a little room but still. What replacement component are you currently trying?
As most of us don't have JTAG probes, may I suggest you include a micro USB receptacle for firmware upgrades over DFU. The uC has built in support in the bootloader + you could use the same fw upgrade tool that is being developed for the Netduino itself....or is perhaps fw upgrade performed over the GoBus?
Writing code for it will probably be both challenging and fun. Have you done this before?
EDIT: Adding a USB receptacle would allow for the board to also be used as a stand alone PC periphal in future. The firmware could later implement a composite USB device comprised of several MIDI class endpoints and a HID protocol for controlling various other aspects and features of the board.
Very nice indeed.
Just out of curiosity, what optocoupler are you using?
Being involved in hobby MIDI hardware design myself, I have spent considerable time researching and studying various MIDI schematics and I don't understand two things:
1) Why is 6N138 ever used? (It is very slow and why Darlington output for on/off switch?)
2) Where is the constant current source in the MIDI current loop? (Or why is it called current loop if it does not work like one?)
So I am curious to see your schematic
The JTAG connector is for me during development. For the real module, I'd do the firmware upgrades over the usual GoBus mechanisms. I wouldn't expect a typical user to have any need for this connector.
Use
Yes, this would let you hook up a keyboard and control the Netduino Go, or (the more practical approach) let the Netduino Go control one or more synthesizer modules. The primary use-case for this is the mother of all sequencers, but you can bite off much smaller chunks for smaller projects.
Isolator
The isolator I'm trying out (important to note that I'm trying it out, I haven't yet proven it will work with MIDI) is this:
Silicon Labs Si8711AC-B-IS. It's new technology, comparatively priced, and includes the pull-up resistor in the package. It's also much smaller and much faster than a 6n138/7. Pinout is different here only because it's the one with the built-in resistor, otherwise it's a drop-in replacement (in a smaller package).
Instead of using an LED, it emulates one using an RF carrier. Pretty clever.
It has a lot of other really nice attributes. If you're familiar with opto isolators, check out the data sheet.
I couldn't get to sleep last night because I had an idea that I had to try out, and my wife was up coughing. I hopped out of bed and banged out two simple boards which have been submitted to DFRobot for manufacturing.
What I've decided to do is make this whole approach more modular and much more flexible. I've designed a couple DIN boards which have two, three, four, or six 5 pin DIN connectors on them. Here's the six connector version and the four connector version (the only two currently designed, but two and three connector versions will be essential)
Now the GoBus module simply has a number of connectors which you can use for the DIN board (and other things).
This lets you use the DIN board if you want, or panel-mounted DIN connectors if you prefer (more practical in some setups), but more importantly, lets you allocate the DIN sockets any way you want, as long as the main module supports it. Finally, it helps reduce potentially long runs of GoBus cables by instead using longer runs for the much slower MIDI and DIN connections. All the mounting holes are on 5mm centers, so if you want a stable platform to play with the stuff, you can use the ones from Nwazet or Tamiya (and presumably others).
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Silicon Labs Si8711AC-B-IS. It's new technology, comparatively priced, and includes the pull-up resistor in the package. It's also much smaller and much faster than a 6n138/7.
Oh, this is really interesting device, thanks for sharing.
One thing that I've noticed in the datasheet is rather high maximum forward voltage VF(ON) = 2.8 V, which means in the worst case scenario and using three 220 ? resistors from the MIDI reference schematic, for 5 V power supply the current IF = (5 - 2.8)/3*220 = 3.33 mA, which is very close to its threshold value IF(TH) = 3 mA. In order to get the recommended 5 mA (as per the MIDI specification), you'd need 0 ? (in addition to those two 220 ? resistors in the transmitter)
Nitpicking corner: it's much faster than 6N138 (propagation delay 30? ~ 60 ns vs. 7 ~ 50 µs), but comparable to 6N137 (20 ~ 75 ns).
You're correct on the speed, of course. I had originally looked at the Si8660 series from them (also new and based on the same tech), so I still had its speed in mind. It does 150Mbps:
Interestingly, I don't see a Input Forward Voltage quoted in this PDF, even though they are based on the same underlying principle.
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
You're correct on the speed, of course. I had originally looked at the Si8660 series from them (also new and based on the same tech), so I still had its speed in mind. It does 150Mbps: http://www.mouser.co...i866x-41125.pdf
Interestingly, I don't see a Input Forward Voltage quoted in this PDF, even though they are based on the same underlying principle.
Oh, I see. Impressive. If I understand it correctly, these are voltage controlled (don't have LED emulator like Si87xx series), so there will be only very small voltage drop caused by the resistance of the internal MOSFETs (?). Also, unlike Si87xx series and the other optocouplers (6N13x etc.), these have non-inverting outputs.
You mean these devices use radio frequency, rather than IR?
Pete, you forgot to mention your view on including a USB receptacle. For optional standalone operation, you could always have the landing pattern and traces to the relevant MCU pins but leave it all unpopulated for future use with new firmware to support it.
You mean these devices use radio frequency, rather than IR?
Pete, you forgot to mention your view on including a USB receptacle. For optional standalone operation, you could always have the landing pattern and traces to the relevant MCU pins but leave it all unpopulated for future use with new firmware to support it.
I've thought of this, but I don't want to put everything on a single board. USB, WiFi, and Ethernet (all of which have MIDI implementations) seem like they'd be better off using regular modules. However, at the same time, using off the shelf modules for those wouldn't provide any on-module filtering or the other smarts.
There's a trade-off. The more I put on a single module, the less it makes sense to have as a GoBus module, and the less folks will be able to hack it using NETMF. However, integrated stuff can perform faster. I could easily do this entire thing as a single board or two with everything in C, but I want folks to be able to assemble stuff. I'm still sorting out where the lines are.
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
You mean these devices use radio frequency, rather than IR?
Forgot to answer this as well. Yes, I believe they are radio frequency. And yes, classic MIDI is slow, but it's very easy to add unwanted jitter/delay in there. USB MIDI is quite a bit faster, but due to USB driver architectures, tends to have *more* jitter.
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Oh, so the board will run .NET MF then, i.e. it's kind of a Netduino 2 clone with native MIDI processing?
The intent is for this board to be a module. You'd hook it up to your Netduino Go just like you would a button module or shield module.
The module has a lot of on-board logic to help lighten the load on the Netduino Go. Think of it as a MIDI co-processor
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
I haven't worked on this in quite a while. At the time, the GoBus stuff wasn't ready for the processors I was using (I haven't since checked to see if they're ready).
If there's interest, I may take it back up in the fall.
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
I sure hope that you will. This shows real progress with custom gear. So I have a couple of additional and semi-related questions. How about a board with USB that reports the available ports to Windows so that a computer sequencers can use them?
Also, and I am stretching this one as it is nowhere near "related", but are you allowed to share what is going on with the MIDI API in the "WindowsPreview"?
Netduino GoBus module: ok, thanks. I'll check back in and see where the various firmware options are and go from there. I was blocked on firmware state last time I checked. I've been out of touch on GoBus for a bit
The USB part would be interesting. I haven't written code to report as a class device, but it should be reasonable to do.
Windows.devices.midi: Jason and I introduced this at our build session, and released a preview version on NuGet. Since then, we've had both individuals and major software companies testing it out. We'll have the release version rolled into the next version of Windows as a proper WinRT API for both universal apps and for desktop. I'm pretty excited about that and the other audio and video work we're doing
Pete
Pete Brown - http://10rem.net (NETMF, C++, Windows, C64, and general geekery) Twitter: @pete_brown I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
There is a thread (I cannot paste the URL so I hope I typed that right) http://forums.netdui...ion/#entry58827 with some info and it has yet another link that I posted to an article on MSDN by Donn (not Donna) Morse. It is about an HID based sensor with Netduino which I am not sure applies to the USB MIDI class compliance.