Thanks Chris, that's great. Jeremy

Is there anywhere I can download the source for this firmware? I've seen a couple of other people post this question but I haven't seen an answer. Or is the firmware source not going to be released until it goes gold? Thanks Jeremy

Hey Ken Well done, and 54 out of 75 is higher than anything I got out in the wilds of the countryside! What I found with the RDS was that I had to tell the device to listen for it for a while. I've written some proof of concept code for it, but as I said before it's a bit of a tangled mess, but it definitely gets text out of the signal. I'll look at the code again this weekend and have a go at tidying it up - but as I remember, the process is: 1. Look at the RDS bit after tuning to a strong channel - keep polling until it until it indicates there's RDS data. 2. When it finds there is RDS data, look at the RDSA, RDSB, RDSC and RDSD registers (details are in data sheet). 3. First look at the RDSA register, shift by 11 bits, if it equals 0 or 1 then it's the station name, if it's 5 or 6 then it's the station information. 4. If you're looking at the station information, then look at the values of the RDSD register - split the dataword into two bytes, convert each from a byte to corresponding ascii character. 5. If you're looking at the station information, then look at the values of the RDSC and RDSD register - split the two datawords into four bytes, convert each from a byte to corresponding ascii character. 6. Build up consecutive letters to make up the station name and information. I've found that station name only ever has 8 characters, station information has many more. I imagine you'll actually have it cracked by this weekend anyway, let me know if you do, but if not I'll try to help out. Hope this is helpful, Jeremy

Yeah that's a good question, I think that A5 is a clock pulse so it's not analogue. I think the A4 (SDIO) sends logic pulses, rather than a clock signal. But it's completely possible I'm wrong, there's guys like Stefan, CW2 and Mario (and others too!) who know how to explain it much better than me. I'm watching the forum thread below with interest It seems to be very relevant to our discussion! http://forums.netdui...64-i2c-voltage/ Jeremy

Hi Ken To be honest, everything you've put in the last post pretty much covered I've got at home on RDS. Certainly I think your code looks ok - I've found that some channels initially report 'No RDS', but if I poll for a few seconds like in the Arduino code, the RDS comes up. Have you tried polling, say for 60 seconds to see if anything appears in the RDS registers? Jeremy

You've got me interested in this breakout board again, I think we can improve the Programme Service Name code a little - in the PrintRadioName method, I put the RDSB value and text into a DictionaryEntry object, but I think it would be better to store

( (this.Si4703_Registers[RDSB] & 0x00FF) & 0x3) * 2;

So this time, each of the pairs of letters will be associated with the numbers 0, 2, 4, and 6, and therefore you can determine the correct order of the letters and what letters come first.

Jeremy

Hi Ken A4 and A5 are the pins for I2C - there's a great post here http://forums.netdui...5-pinout-cards/ I have the netduino plus card printed out and refer to it pretty much every day Jeremy

Hi Ken - excellent news! I'll update my code here as well, I'm happy you've found how to make it better

What might be interesting to you as well is if you want to see the radio text information, you can use

if ((this.Si4703_Registers[RDSB] >> 11) == 4 || (this.Si4703_Registers[RDSB] >> 11) == 5)
            {
                int Ch = (this.Si4703_Registers[RDSC] & 0xFF00) >> 8;
                int Cl = (this.Si4703_Registers[RDSC] & 0x00FF);
                int Dh = (this.Si4703_Registers[RDSD] & 0xFF00) >> 8;
                int Dl = (this.Si4703_Registers[RDSD] & 0x00FF);

... and convert to ascii, and then the rest of the code goes here, with minor modifications

That's an interesting question about the two boards from one Netduino. I don't know enough about the I2C protocol right now to answer that unfortunately. If you've got two FM boards (even if the first one is only partially working) you might be able to try it, but I guess you might have to revisit the original code and try to eliminate static variables. I don't know how two devices with the same device identifier on the same I2C pins would work - I'd guess it would conflict, because the netduino can't determine which device to talk to at any one time? But it's just a guess.

Cheers,
Jeremy

Hey Ken

Try this, it's only a proof of concept I put together in 20 minutes, so it's not good code or even remotely robust, but it'll get you started I hope:

Add "using System.Collections;" to the Si4703 class I uploaded before.

Also add this code to the same class.

public string PrintRadioName()
        {
            int j = 0;
            string token = "";
            string fullRadioName = "";
            while (true && j < 500)
            {
                j++;
                this.ReadRegisters();
                if ((this.Si4703_Registers[Si4703.STATUSRSSI] & (1 << Si4703.RDSR)) > 1)
                {
                    var radioNameSoFar = this.ReadRadioName();
                    if (radioNameSoFar != null)
                    {
                        if (token != (string)radioNameSoFar.Value)
                        {
                            token = (string)radioNameSoFar.Value;
                            fullRadioName += radioNameSoFar.Value;
                        }

                        if (fullRadioName.Length > 16)
                        {
                            return fullRadioName;
                        }
                    }
                }
            }
            return string.Empty;
        }

        public DictionaryEntry ReadRadioName()
        {
            if ((this.Si4703_Registers[RDSB] >> 11) == 0 || (this.Si4703_Registers[RDSB] >> 11) == 1)
            {
                int Dh = (this.Si4703_Registers[RDSD] & 0xFF00) >> 8;
                int Dl = (this.Si4703_Registers[RDSD] & 0x00FF);

                int infoOrder = (this.Si4703_Registers[RDSB] & 0x00FF);

                var radioName = new System.Text.UTF8Encoding();
                byte blockerrors = (byte)((this.Si4703_Registers[STATUSRSSI] & 0x0600) >> 9); //Mask in BLERA

                DictionaryEntry d;

                if (blockerrors == 0)
                {
                    if ((Dh >= 32 && Dh <= 127) && (Dl >= 32 && Dl <= 127))
                    {
                        var radioChars = radioName.GetChars(new byte[] { (byte)Dh, (byte)Dl });
                        d = new DictionaryEntry(infoOrder, "" + radioChars[0] + radioChars[1]);
                        return d;
                    }
                }
            }
            return null;
        }

And call the "PrintRadioName" method after you tune to a radio station with a strong signal. If there's something there, it should return it into a string variable. I was able to get some RDS information with this, so hopefully it'll work in your part of the world too. Anyway, give it a try and let me know what happens.

Jeremy

Hey Ken I've attached the 3 files I think you need to get started - I've tried to keep it close to the Arduino code so it's easy to compare the two. Once you've got the Netduino and Si4703 talking, getting the RDS data is pretty easy. If you hit any problems with that, give me a shout, I've got another class that outputs the channel name and description, but it's seriously not pretty code. I have been using the Sparkfun breakout board, here are the pins I used. Vcc - 3v3 GND - Gnd SDIO - A4 SCLK - A5 !SEN - n/c !RST - D2 GPIO1 - n/c GPIO2 - n/c As with any of these sorts of things, works on my hardware, but use at your own risk... Let me know how it works out, Jeremy

Hi Ken, I've done this with the Netduino already - the tricky part is that you need to do a little manipulation with the array you use to read and write to the registers, I think that when you start reading the first word that comes out is at 0x0A rather than 0x00. But porting from Arduino to Netduino is definitely possible. If you're interested I'll try to resurrect the code from my development machine, just let me know. Jeremy

The short answer is that I am sure the interrupts are being lost in the middle of the signal. Longer answer - I've been writing the values of pulse durations to the console, and one example is below: 1(7893120) // presence pulse 1(207573) // presence pulse 1(1707) // presence pulse 0(853) 0(853) 1(1067) 1(1280) 0(853) 0(854) 0(640) 1(1280) 0(853) 0(640) 0(853) 0(854) 0(640) 0(853) 0(853) 0(640) 0(854) 0(853) 0(640) 1(6187) // suspect 0(640) 0(853) 0(853) 0(640) 0(854) 0(853) 0(640) 0(853) 1(1280) 0(854) 0(640) 0(853) 1(1280) 1(1280) 1(1067) 0(0) // never populated 0(0) // never populated 0(0) // never populated 0(0) // never populated 0(0) // never populated (Timing values in ticks are in brackets for the 43 positions, preceded by the corresponding derived logic values.) So you can see that the netduino only reckons there were 38 falling egdes - the last five positions in the array have empty timing values because they're never populated by an interrupt event. At edge 23, it believes the length of the pulse is 6187 ticks. This is why I believe that the interrupts are being lost mid-stream, rather than at the beginning or the end. My guess is that is actually 6 successive pulses of length 1280 + 854 + 1280 + 1280 + 853 + 640 being rolled into one, but I can't tell what order (I guess it should end up being 101100). So the 5 bytes I actually try to process are: 00110001 00000000 // 49 Relative Humidity - about right 00010000 00001000 // 2064 degrees Celcius - bit warm 11100000 // checksum indicates the numbers are wrong And I think the 5 bytes I should be processing are: 00110001 00000000 // 49 Relative Humidity - about right 00010110 00000000 // 22 degrees Celcius - about right 01000111 // checksum indicates numbers are right So I'm not sure if this related to the FIFO change to the interrupt queue - but I'm not sure that I understand how that change fixes BitFlipper's issue 1073 either! Might this be a new bug? Jeremy

Hi there I've been working on a DHT11 as well - I wonder if the the problem is interrupt information going missing from the queue. Basically I've tweaked CW2's code on my development machine to look at the DHT11 signal in a different way - as each falling interrupts edge comes through, I put the number of ticks since the last one into an integer array. If the number of ticks is greater than the BitThreshold, then it's a 1 - less than the BitThreshold means it's a 0. So according to the datasheet (and my experimentation), we should expect 43 trailing edges in a complete signal (3 during the initial handshaking, and then 40 for each bit of temperature/humidity/checksum information. (For my Netduino, 640/853/854 ticks represents a logic 0, and 1067/1280 represents a logic 1. This pattern is very consistent on my hardware, but YMMV.) Under Netduino firmware 4.1.0.6, I usually saw 43 trailing edges before communication stopped, but sometimes saw 42 - it seemed to lose one bit of data around position 23 for me. The failing position would usually have a value like 2560 ticks, which I guess meant it was two logic 1s that run into each other. So I think that somehow the falling edges are not being queued correctly. I've just updated my Netduino to firmware version 4.2.0.0 RC5, and now I'm only seeing a max of 30 - 40 falling edges before communication stops. Does anyone have any thoughts on this - is it a problem that's been solved? Or is there a maximum number of interrupts that can be queued in the buffer before it overflows? Or should I be posting this question in the 4.2.0.0 RC5 Firmware Beta page? Thanks for any help! Jeremy

Hi magarcan

I've been having a look at the problem you've described (since I've been working on some serial port things myself).

First, I'm assuming you've got D0 (COM1 Rx) connected to D3 (COM2 Tx), and D1 (COM1 Tx) connected to D2 (COM2 Rx) here.

Given that, if you look in the SerialPortHelper.cs class, the serialPort variable is declared as static (as are buffer and
bufferlength). I think what's happening is that since you've instantiated two separate ports in your class, you're actually sharing
resources between them. So when an event is fired to say "data has been written to COM1", the code reacts to that event
by trying to read from COM2. If you leave the serialPort variable as static, and change the serialPort_DataReceived
method to look like the code below, you'll see what i mean:

private void serialPort_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
    // i expect these to both return the same port
    // if serial port is static, i find they're different.
    Debug.Print("serial port name = " + serialPort.PortName);
    Debug.Print("sender name = " + ((SerialPort)sender).PortName);
    lock (buffer)
    {
        if (serialPort.BytesToRead > 0)
        {
            int bytesReceived = serialPort.Read(buffer, bufferLength, bufferMax - bufferLength);

            if (bytesReceived > 0)
            {
                bufferLength += bytesReceived;
                if (bufferLength >= bufferMax)
                    throw new ApplicationException("Buffer Overflow.  Send shorter lines, or increase lineBufferMax.");
            }
        }
    }
}

So basically I think if you use the method above, and remove the static modifier from the serialPort variable, you
should make some progress. You might want to remove static from the other two member variables too.

I guess you'll also have noticed I added a little bit to that code to check if there's at least one byte to read from serialPort.
Stepping through your program slowly in debug mode gives me different behaviour to when I just run it
without breakpoints - I found there was an exception in this method because whereas we've been notified that data has
been received, when I actually look at the serialPort.BytesToRead property I find that there's nothing there. I couldn't
work out why the event was being fired, if you have an answer I would be really interested to know!

But this looks like a great library, it's interesting to me as well.

I hope this helps - let me know how it works out.

Jeremy

Hi there I've built this firmware with the changes to the 'slow clock' time, but I'm not seeing any improvement in performance in my DHT11. Is there a command to query the Netduino properties to find the slow clock time? I just want to check that my new binaries actually have this change built into them. Thanks, Jeremy

Hi CW2 - thanks for this, I just saw this reply, sorry for not replying sooner! I'll try it and let you know how I get on, Jeremy

Hi again - no luck with the DHT11 after increasing my firmware resolution I'm afraid. My firmware is definitely now running at 375kHz, and the Netduino doesn't seem to be distinctly seeing all 43 pulses for each temperature/humidity reading (usually half that or less). Oh well. (This is of course just on my system - other people's mileage may vary.)

Hey willgeorge No problems at all! I'm really glad you were able to use it Jeremy

Hey everyone I just bought a HMC588CL magnetometer, and after a bit of googling I haven't found any records of existing Netduino code for getting started with it. So since I've got mine working, I've attached my code. Let me know if there's any bugs in my code, but hopefully not - you'll see that it's very simple code - the application doesn't really do anything except output the X and Y readings, but it gets you started with the device. You can use these readings to calculate your bearing from North. I hope someone out there in the community finds a use for it in a project! Cheers, Jeremy

Hey liqdfire and Mario Thank you so much for this help and information - I've been getting through it this weekend and think I've got a better (and more object oriented) solution to my problem with your help. Thanks again, Jeremy

Hi everybody I've got a question about Serial port communication using the netduino. This is the first time I've built something like this - my first week with a Netduino - but I hope this isn't a dumb question!!!. Where I've got to so far: I'm using a barebone FTDI USB to Serial mini adapter - I open COM1 at 115200, and repeatedly send a byte array (each packet being 16 bytes long) from my netduino. I also have a C# client application which reads from the com port at 115200, and successfully sees the stream of bytes that I'm sending from the netduino. So far so good. Where I'm hitting the problem: The client application isn't able to determine where my packets of 16 bytes start and end. I mean if I tell the my client app to read 16 bytes from the port, I find that it's possible it'll pick up the last 7 bytes of one packet and then the first 9 bytes of the second. I think this is probably expected behaviour. My current workaround is a bit of code that looks for a certain byte pattern in what comes in from COM1 - when it finds that, then read the next 16 bytes of data and assume it's a valid packet of my data - and I just repeat that. But do you guys know if there's a more elegant or robust solution to my problem, or if there's a protocol I should look into using to tokenise my data stream? Thanks in advance for any help! Jeremy

Hey Stefan and Liqdfire Thank you for the assists - it sounds like the answer for me is to develop a custom solution, like you say maybe have a unique "end of packet" sequence. Liqdfire - If you do get a chance to post some code that would be really great - in the meantime, I'll spend a bit of time coding up a solution and post my code when I'm done. Hopefully this thread will help someone else out if they hit the same problem. Thanks again, Jeremy

Hi BitFlipper Could you confirm if the fix in .NET MF4.2 for issue 1073 (http://netmf.codeple...m/workitem/1073) actually solved the problem for you? I'm coming across a similar InterruptPort issue myself and just wanted to check if your issue was resolved by the change. Thanks! Jeremy

Hi BitFlipper - thanks for replying, that's useful information anyway. My issue sounds possibly related to yours. I've a sensor sending 43 bits of information, and the Netduino only picks up around 30-40 - I've found that it "loses" interrupts in the middle of the signal. I'll keep looking for a solution Thanks again, Jeremy

Hey Hackaroth Very nice! I've been toying with the idea of buying one of these and I think you've convinced me Jeremy