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.
Hi there!
My project is about creating a networked music player using the Netduino mini and a vs1053 mp3 decoder chip. I know there are lots of streming music players out there alyready and even though I got some special plans for my little baby, I'm mostly doing this for the pleasure of it.
Currently, I'm kinda concept proofing, but it's going pretty well. Got the mini hooked up to a vs1053 breakout board from Sparkfun (rectified version), SD card, a pushable rotary encoder and a class D amplifier chip from Texas connected to a pair of monitor speakers. The latter is merely for sound quality testing and playing my favourite tunes while working with the project
Anyway, attached is an image of how it all currently looks. Topmost is the 2x25W @ 4 ohm class D amplifier board based on the TPA3123 from TI which is pretty much a T-amp. Below that is my breadboard and from left to right, the black rotary to adjust volume and skipping forward through songs (mp3, wma, AAC, Flac, waw, MIDI, PCM and Ogg Vorbis, etc). Then there's the VLSI vs1053 digital music decoder bob, the Netduino mini of course and the SD.
I think the Netduino and NETMF really rocks as a means of prototyping and the vs1053 is one bad boy when it comes to audio.
As you can see for your selves, my girl ain't pretty, but boy can she can play
My next major step will be to add TCP/IP networking using a MRF24WB0MB radio tranceiver from Microchip. I should probably start with a wire bound Wiznet, but I'll give it a try first.
Best wishes, all!
My project is about creating a networked music player using the Netduino mini and a vs1053 mp3 decoder chip. I know there are lots of streming music players out there alyready and even though I got some special plans for my little baby, I'm mostly doing this for the pleasure of it.
Which version of the vs1053 product did you use? Sparkfun returns a few results when searching on vs1053.
Since I contacted them regarding an issue with the TEST/DREQ pins, they've corrected their bob by soldering a jumperwire from the TEST pin to IOVDD. Excellent customer care there!
The project sounds good (in all ways ), but...I am sorry, but I can't understand what is the actual Netduino role in this project.
Mario
Hi Mario!
Well, the Netduino mini controls the vs1053 digital music decoder and the SD card as two slaves on a shared SPI bus. The rotary encoder generates interupts for the Netduio to interpret and perform the corresponding volume adjustment on the vs1053 as well as skipping to the next song, i.e. start reading a different file from SD.
During playback, the Netduino orchestrates the streaming of mp3 files from SD card to the vs1053 via an internal 16 kB cyclic read ahead buffer (basically a FIFO) in RAM, while simultanoously keeping track of the rotary and more to come.
Ok, during normal operation the Netduino mostly shuvels data from SD to vs1053, and sure, I could have done this by uploading custom software into the vs1053 thus omitting the Netduino. But I could never have done that in 2 weeks time and not in C# and the full confort of Visual Studio 2010 with all that comes with it terms of debugging capabilities and so forth. Especially not since I'm a software man and haven't dealt with any type of MCU whatsoever until about a month ago.
During playback, the Netduino orchestrates the streaming of mp3 files from SD card to the vs1053 via an internal 16 kB cyclic read ahead buffer (basically a FIFO) in RAM, while simultanoously keeping track of the rotary and more to come.
What? Let's consider a MP3 song played at 128KB/s (maybe less), that is 16KBytes/s. Did you written a C# program that is able to flow 16KBy/s, without any native driver?
Let me know a little more about.
Cheers
Mario
Biggest fault of Netduino? It runs by electricity.
Whilst messing around with some web server code here I decided to test how fast I could deliver files from the SD card over http. The Netduino managed a very respectable 95kB/s - serving up a 256MB video file in about 4 minutes.
I have realized that the data transfer to/from SPI (or TCP/IP) is very fast, because it is made by the low level libraries. If you try to search among the latest threads, I had a problem (big word) on reading ADCs. That is a very common activity, with tons of apps, but it seems there's no way to do without hacking something in C++.
That is a pity.
This thread is pushing me to think seriously toward some missing blocks of this framework. It has no sense that you may transfer KB/sec and there are many difficulties to perform even the most basic activities.
That is surely a big fault.
Mario
Biggest fault of Netduino? It runs by electricity.
Chris, I am not having any problem at all, from the hardware and firmware viewpoint: the device does exactly what it says.
Now the risk is going a bit off-topic, but I think there are some considerations to do about Netduino+NetMF and the driver set.
Fred shown us that the http networking is able to run up to 95KB/s: absolutely wonderful.
Hanzibal is able to transfer 32KB/s (192Kb/s) from to SPIs: over than expected.
These functions are quite fast because the managed part is minimal and the dirty work is done by native code. However Netduino is *not* a PC and it best fits to integrate with hardware stuffs. So I think that it should be greatly improved in the MF the ability to interface hardware, while the managed part should only the glue-logic.
Just to make some examples...
Reading periodically one or more ADCs is a very very common activity. There are tons of applications around it: digital filtering, smart-sensors, data streaming, etc. The problem is that is *not* possible until you write a custom driver in C++. Via C#, I think I can't reach over 100samples/s.
That's the way it should be present a kind of "ADC sampler" or whatever else.
Also reading I/O ports is very common, but toggling a single pin takes over 100us. Why there is not any "read/write-all-pins"?
Closing...
I have noticed that the C#+NetMF give an high level of abstraction than the classic native coding, but that is costing too much for practical applications. I really think that we should consider some more "hardware-oriented" API to circumvent the limitations of the current device.
I am ready to work on, if you need.
Cheers
Biggest fault of Netduino? It runs by electricity.
Made a few tests and even 320kbps (48kHz sampling rate) CBR mp3 files plays beautyfully. As I gather, 320kbps (kilobits per second) corresponds to 40kB/s (kilobytes per second) as one byte is 8 bits and so 192kbps is equal to 24kB/s.
SPI clock speeds used are 5 MHz for the vs1053 and probably a great deal faster for SD. I've been asking questions in the forum trying to find out actual SD speed but haven't got any replies yet. I haven't got a scope or analyzer yet, but maybe someone could please check for me?
EDIT: Found out from Chris that SD clock speed is 10 Mhz.
My only sound related problem right now, is a low level background beep which I think is coming from SPI speed switches. These are creating spikes that are induced and transferred to the amplifier. The beep has different frequencies depending on the bitrate of the song being played due to different intervals between SD reads. Also the beep disappears for a short while when skipping to another song as no SD reads take place during a deliberate delay in code.
Any ideas of how to get rid of the beep?
Yesterday I started a C# port of Async Labs uIp driver for ZG2100 as I suspect that be pretty much the same chip as MRF24WB0MB from Microchip since they took over ZeroG. Documentation is close to nothing on both and I guess that's because of license NDAs or similar.
Anyway, attached is an image of my homemade MRF24WB0MB breakout board. At one point I think I got Netduino talk SPI to the thing but I messed up while trying to read debug messages from the MRF24WB0MB and now my mini needs reflashing or worse.
Nope, the ZG2100 is not quite the same as MRF24WB0MB. Instead I'm now rewriting the driver based on the code for Light Shield 7 of SaikoLED which is based on the Async Labs stack, which in turn is based on the uIP stack from Andreas Dunkel
With the help of Chris and Fred, I managed to resurrect my mini last night. Now it seems as if I've somehow flawed the wifi chip though so a new one is on it's way.
With any luck, I'll hope to have the driver up and running soon...
Anyway, attached is an image of how it all currently looks. Topmost is the 2x25W @ 4 ohm class D amplifier board based on the TPA3123 from TI which is pretty much a T-amp. Below that is my breadboard and from left to right, the black rotary to adjust volume and skipping forward through songs (mp3, wma, AAC, Flac, waw, MIDI, PCM and Ogg Vorbis, etc). Then there's the VLSI vs1053 digital music decoder bob, the Netduino mini of course and the SD.
I think the Netduino and NETMF really rocks as a means of prototyping and the vs1053 is one bad boy when it comes to audio.
As you can see for your selves, my girl ain't pretty, but boy can she can play 
My next major step will be to add TCP/IP networking using a MRF24WB0MB radio tranceiver from Microchip. I should probably start with a wire bound Wiznet, but I'll give it a try first.
Best wishes, all!
Netduino-vs1053b.JPG 35.42KB
429 downloads
