I remember  initially having quite some trouble with getting the chip to play. My problems turned out to be SPI related and at some point, I got a faulty GPIO pin connected to DREQ which was really hard to track down.

 

If you haven't already, take a look at this post:

http://forums.netdui...decoder-solved/

 

I posted on the VLSI support forums and among others, there's this one:

http://www.vsdsp-for....php?f=11&t=277

 

I've made many more posts on the vs1053b department of the VLSI forum. Please do search for my posts over there and I'm pretty sure you will find something useful:

http://www.vsdsp-for...id=298&sr=posts

 

Hope this helps!

I don't have smart meter but I've made a light detector that detects pulses coming from a LED indicator on the meter fitted in the electricity central cabinet on the outside of my house. The LED pulses once for every half kW (or so) and my detector transfers the pulse via a 433Mhz radio link to a logger inside the house. I guess it's similar but only unidirectional and I suppose the meter with the LED indicator is a smart meter but it's owned by the electricity company.

So, basically you're running the same s/w as me, then it ought to work especially on a faster uC. Well, at least one would think so but... Here's the thread I was thinking about in my last post: http://forums.netdui...ge-3#entry44437 It took me a while before I realized it's my own old thread but I believe it might be very relevant indeed from the post referred to and onwards, so read it carefully.

Sample rate and stereo/mono mode are properties of the song you are playing and so they depend on how each song was recorded. I added this info just for fun and it should not effect how well or poor a song is played. By the sound of it, you are suffering from poor transfer rate between the SD card (songs are on an SD card right?) and the vs1053b. If you look into my code, you can see that I crank up SPI speed as part of initialization. Have you incorporated that part into your code? Also I remember someone else had similar problems not all that long ago where I tried to help. Use google to search the forum for "vs1053b", the forum search does not work very well (or maybe it does now). Also, you cannot have Debug.Print in performance critical parts of your code, it will slow you down a great deal. I assume you don't use interrupts for DREQ since it too will add significant overhead. You must poll DREQ in a tight loop and then feed the chip fresh chunks of 32 bytes each as quickly as you can until DREQ changes again to indicate the buffer is now full and cannot accept any more data until the chip has consumed what you just fed it. Now, I did this with a mini which is considerably slower that an NP2 but I recall there were some problems mentioned in the thread I mentioned above.

Wow, hanzibal, you've been busy Very nice! Chris

Thank you, I hope you didn't mind me writing about the board here on the forum. It's not commercially available (yet) though but a first batch of 200 have been ready for some time while I've been "perfecting" the software :-) Coding is very much inspired from my experiences with .NETMF in general and Netduino in particular. In many cases, I've actually been reusing code in both directions. Would you mind if I write a separate post about the board?

For your 1st question, I'd like to add that, since you have a Netduino Plus, a nice way of doing that would be to use networking. That is, you would write a socket listener (or use one of the ready made webbservers available here on the forum) for performing tasks initiated by a PC application. You can also use a USB-to serial converter to communicate with one of the Netduino UARTs. It's also possible to implement a HID device on your Netduino but I think this would be the more cumbersome code wise.

Here's the other two videos, it seems one cannot include more than two videos in one post.

 

You should be able to find lot's of stuff regarding motor control here on the forum.

As for the PC comm I've made a USB device called PeekyPokey that acts as a virtual COM port and HID device on the PC (talks to Netduino via serial) and has 8 gpio. It comes with an extensive library in the form of an easy to use .NET assembly.

 

Below are a couple of videos of the board that, in order of appearance, 1) shows interaction with a Netduino mini (and a 2nd board), 2) controlling servos, 3) controlling a stepper motor and 4) controlling an LCD.

 

 

 

As can be seen in the videos, the library contains controls in the form of virtual LEDs, buttons and such that can be used for controlling stuff. It also contains USB game pad (joystick) support and a web server (last video).

 

I use the board a lot with my Netduino mini's since it can program/debug the mini, interact with it and power it.

@Silent Walarus:

May I ask what sensor you would be getting the analogue readings from?

There aren't many USB<->analogue boards and if you find one, its likely to be much more expensive than a regular USB<->serial cable.

The Netduino is much better at dealing with analogue than a PC. Depending on your requirements, I think you'd be much better off letting your Netduino do the analogue readings. If your PC app needs the analogue readings, your Netduino could easily send them to the PC using a USB<->serial cable. From the PC app point of view, it's simply a matter of reading/writing to a COM port. You could define your own protocol for sending messages back and forth and having the Netduino perform various tasks initiated by commands sent from the PC app. Same thing on the Netduino side of things, simply read/write to a COM port.

The PeekyPokey is a PC<->Serial and PC<->GPIO combo and cannot operate without the supervision from a PC app running in the other end of the USB cable.

Here's what I think you should do next:

1. Get a USB<->UART (3V3) converter cable like this classic one:
https://www.sparkfun.com/products/9717

or a cheap board like this one:
http://www.ebay.com/...=item484bf4eb2f

2. Hook up your Netduino to your PC via the above cable/board:

Netduino ---------------------- Cable/board
UART_Tx ---------------------- Rx
UART_Rx ---------------------- Tx
GND --------------------------- GND

3. Find some code for doing serial talk from the forum (there are hundreds of posts regarding that)
http://lmgtfy.com/?q...UART Read Write

4. Using that info, write a small program to send the string "Hello world" from your Netduino to your PC

5. Implement your own serial protocol for data interchange and command execution

6. Start working on that sensor (if possible, have the Netduino do the readings)

7. Have tons of fun!

Where have you been during your time in exile?

Ok, there are of course much more sophisticated hp-filter designs that you could apply.

Totally awsome Mario, great work!

So you want to be able to use a mechanical switch to cut power to the board regardless of whether it is currently being powered by the 2.1mm barrel or USB. Correct?

Yes, cutting ground only should work so an spst would do, I didn't think of that.

Ok, so basically you'll be using a software hp filter then, I suppose there are ready made functions for that in LabView but designing one in h/w is quite simple, basically you put a capacitor in series with a resistor to ground.

Good, then it was as I suspected and also the solution was the one I suggested earlier:

 

Also, I see you got rid of the redundant calls to IndexOf (as I also mentioned).

So am I apparently :-) EDIT: Exchanged "are we" for "am I".

Ah, yes that was a typo, I meant to write "[][]", sorry for messing it up. I use that construct quite a lot, just didn't know it is called a "jagged" array.

Of curiosity, a "jagged" array would be one like this in C# right? bool[][] bColors = new bool[]{ new bool[]{ false, true, true}, new bool[]{ true, false, true}};

Couldn't you just invert the signal (turning valleys into peaks) and then apply a peak detector on that?

I meant for you to subtract the signal from a positive voltage. EDIT: Deleted an erronous statement.

Also, IndexOf always returns -1 if not found.

In C# it does but are you sure it does so in VB too?

It doesn't seem to judging from the solution and VB is traditionally 1-based.

A stupid question perhaps, but if the background is also available on its own (without the square wave) a differential amplifier would do the job. I suspect not but provided the 8 - 10V signal varies significantly less (slower) than the square wave, you can use a high pass filter to isolate the square wave which could then be amplified. That is, you would design a filter to remove everything below the maximum frequency of the squarewave (e.g. place the knee at ~30Hz).

I don't quite follow, I thought you were trying to detect local minimums but are you in fact trying to filter out the 8V DC component leaving just the square wave?

Ah, I was totally unaware of that, thanks for the info. I really liked the last part about the new operator being "short circuit" so that it only evaluates the true alternative and not both as the old iif did. I guess my VB is gettng a bit rusty from all the C#.