Wow!

Thanks baxter, I'll be sure to make a post when the driver's ready so that I got something to show you.

your radio or host board?  I've flicked pwr_en high and low just fine, so maybe double check the wiring, maybe it's OK!

The radio, when trying to set the pwr_en input pin high by applying 3.3V to it, it seems to result in a short circuit.

Hi guys, I'm back from my holiday now and was looking forward to work on the PCB that I set out to do in Eagle, but... While I was gone, my commercial IO board launched so I need to attend to that in improving the software, writing docs, creating sample projects and so on. This means I won't have time to work on the PCB for a good while. I'll be happy to see someone else pick it up instead and since I didn't get farther than removing the mosfets, there's little point in me posting the Eagle files.

It's based on the RAK410 module, specs are here: http://www.rakwirele...0_Datasheet.pdf To the left is a PeekyPokey used to explore the API since it's more conveniant to do directly from the PC. When I'm done, I'll move the code to the Netduino.

Hmm...now I can't sleep trying to figure that one out :-)

Extremely off topic now: The triangle of binomial coefficients, a.k.a. the triangle of Pythagoras perhaps? But what about monday... EDIT: I'm so stupid, 29 as in your nick will go lay down now. A miscalculation, sleep well! EDIT: Nope, wrong again I think. I actually came to think about the tower of Babel and then found out about Ziggurat: http://en.wikipedia....urat_at_Babylon It was not until I saw the tower that I realized that your avatar depicts it. The number 29 according to the formula has probably something to do with the dimensions of the tower structure. This does not solve the riddle but interesting never the less. I have to give this some more thought and a bit of reading. I find these kind of things highly interesting. Sorry for all the off-topic stuff here guys.

I did try the dead chicken routine but nothing in particular happened (other than our old parrot arising from the dead which was kind of freaky btw).

 

I too have a Bus Pirate laying somewhere, still untouched since I use the scope instead, it works pretty ok for me.

 

Vdd is 3V3 but I might have accidentally applied 5V logic at some point effectively killing the pin (I'm using my own USB explorer board, not a Netduino).

 

Btw, are you also using the older TiWi-SL eval board from LS Research?

I soldered short wires onto pins 7 - 12 on both the J4 and J5 headers (and left all other pins unused), then stuck it down a regular breadboard.

 

 

 

SCI_VOL is a h/w register of the vs1053b chip, so you need to write the value 0x2424 to the register. You do this using the serial command interface (hence the "SCI" prefix) over SPI.

    // Write to an  SCI register
    private void WriteRegister(byte address, ushort data, bool waitForDREQ = true)
    {
        wr_buff[0] = 2;                    // write command
        wr_buff[1] = address;              // register
        wr_buff[2] = (byte)(data >> 8);    // high byte
        wr_buff[3] = (byte)(data & 0xff);  // low byte

        SelectCommand();                   // select SCI
        if (waitForDREQ) AwaitDREQ();      // wait for dreq to go high
        spip.Write(wr_buff);
    }

    // example of setting volume
    WriteRegister(REG_SCI_VOL, 0x2424);

The code snippet above is taken from my source code (puplished earlier).

 

I would use a rotary encoder but if you want to use a potentiometer, you can set it up as a simple voltage divider GND - 3.3V and then read the voltage of the wiper using a Netduino analogue pin. You would then need to add software to continuously poll the analogue pin for any changes in voltage, executing the corresponding volume adjustments.

The 16 bit register is divided into two bytes of 8 bits (256 steps) each, you need to set the two bytes separtely like so:

byte left_vol = 45;
byte right_vol = 90;

ushort vol = (left_vol << 8) + right_vol;

WriteRegister(REG_SCI_VOL, vol);

Great, that you found it useful! I saw your antique radio project and I really love the mix of new and old that you get from putting new internals in old machines. My late mother used to have one similar to yours, you'd have to wait for like 15 minutes for it to get warm before you could use it. Sadly, we didn't keep it. Cheers!

Great to see that something useful came out of this and I hope you were able to reuse some of the code from this thread.

 

Also, thanks for recognizing our work, to which I believe ziggurat29 contributed the most.

Great!

As for multi SPI, I could make an interface for the internal multi SPI mgr implementation of my MCP23S17 driver and expose that from outside the class.

You would then have to make some modificatins to your local mIP code to have it use the interface supplied by me rather than accessing the SPI module directly.

The latter would probably only be a little more than search and replace but still, you would break away from the main track of mIP. This is what I meant before when talking about the lack of a standard multi SPI mgr that can be shared between code originating between different contributors.

EDIT: Just discovered, mIP also includes a multi SPi mgr (borrowed from Stefan Thoolen's Toolbox)...

I'm sorry but I really think you should refrain from posting the entire listing in this thread, not just because it's really long but because it has very little to do with mIP.

Please modify your last post, remove the code and instead attach it as a file to the MCP23S17 thread. In that new post, please also point out any specific problems that you want me to look into.

Sorry post to wrong thread.

When re-reading my last post I realized that I may have sounded grumpy and if so, I'm sorry because I didn't mean to.

You're doing a great job Andy and I'm glad you have taken interest in this. Please do make a new post in the MCP23S17 thread and I'll do my best to help you.

I'm sorry for not being of much help here but I've never dealt with that M2Mqtt.

 

Did you solve the problem eventually?

Good job!

 

I guess it's sort of a bug but mostly because mIP hasn't been tested with all that many routers yet 

 

If you haven't already, could you please report your findings on the mIP CodePlex site or perhaps send a personal message about it Valkyrie-MT briefly describing the problem, what you did to fix it and the name/model of your router?

 

So I take it, you got TCP/IP up and running now then - that's great!

That sounds very familiar to me :-)

Andy, just skip internal pulldown (change the parameter) and put an external resistor instead of some 10k - 100k from the IRQ pin to ground. Could even be, there's already one fitted on your ENC28J60 board.

Also, double check to make sure the IRQ and CS pins are not swapped, parameter-wise that is.

I don't have the code at hand right now but the last two arguments of the Start method are likely the chip select and interrupt pins respectively.

The numbers are just the numerical representations of the corresponing pin constants/enums and so, in your case, you should be able to simply replace those with D10 and D8.

You need to connect the SPI pins (e.g. miso, mosi, clk, !cs), !int and of course vdd and gnd. I beleive the !reset pin to be optional.

I used this board from Sure Electronics:



Even though your board probably looks different, it should have those same pins.

Oh, about the profile, you can either change one of the existing ones or add your own, its only a matter of reflecting which Netduino pins you are actually using.

Check your SPI wiring and again that the CS and IRQ have not been swapped.

Could you post a link pointing to the ethernet board you are using and perhaps also a photo depicting your wiring?

I guess that D8 does not equal (Cpu.Pin)8 in reference to a standard netduino 1?
 
Would this be 62 at a guess?
 
And D10 would be 64?
 
Many thanks
 
Andy

You should be using the constants/enums corresponding to the pins on your Netduino instead of the numerical values from the original code.

Yes, the two ns entries look clashed but it would surprise me if that's not just the print out looking funny.

Bring up a DOS box on your PC and type "nslookup www.google.com", what do you get?

You should get an ip number, try that on your Netduino.

Also try accessing your gateway 192.168.1.254 from your Netduino.

It seems you have no name server configured or one that does not know of netflix.

What happens when you try www.google.com?

It seems name servers does not get configured correctly via DHCP with MIP even though there is one in your network.

Perhaps ns info somehow gets garbled after all - maybe you could debug the method that printed the ns info earlier and see if it is actually stored like that, e.g. if in fact MIP thinks that "192.168.1.1.192.168.1.254" is the configured ns - if so, there could be some problems with string handlng during DHCP processing.