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

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 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

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

Nice! I wish I had seen your post before buying some of these components separately...oh well

Hi - is this kind of what you're looking for? http://forums.netdui...8-bitconverter/ I hope this helps - Jeremy