Thoughtophone

I guess the cross platform part of this library is in it's infancy: Even though most of the ports have a class representing the SPI interface, they are all different classes, with different sets of methods. The interface should be a contract between the RF24 code and the hardware. I've forked the original and got a Chibios port working using this approach. I've also added something that implements a Chibios API - abstract sequential streams , which is so I can use some other Chibios utilities I use in the balancing robot. This is a little half baked and inefficient: I really need to use the RF24 interrupt signal, but it seems like a good idea to get it to work at all first. I should probably prove I have GPIO interrupts working in Chibios by porting one of the other examples first. Now I need to figure out how much I want to apply these changes to the other platforms. I'm most interested in the Raspberry Pi, since it's my current bridge hardware, but it'

I couldn't get pynrf24 to talk to RF24 running on an Arduino. I followed the link from pynrf24 to RF24, but actually there's a more active fork of RF24, with some support for plugging in new platforms. So now I've switched to this more active RF24 library . The general idea is to add Chibios support and submit a pull request. The getting started example didn't work until I explicitly set the channel to 0x60, which was a bit irritating - I spent the best part of an afternoon checking I could really get two devices talking to each other, rather than adding the Chibios support I need. The RF24 library supposedly also includes a python wrapper. I haven't managed to get it to talk to the python client as yet, so hopefully the python wrapper will prove convenient. I suppose what I should actually do is take all this into the office and show it will work there, in a noisier environment. There's one argument against that - and that is that so far I haven't b

Having struggled with the esp8266, I've decided the answer is something I have a little more direct control over. My first, and perhaps only target is the balancing robot. I've started off using pynrf24 : $ git clone https://github.com/jpbarraca/pynrf24.git $ cd pynrf24 This is hopefully the shortest path for me: I already have a python program that acts as the bridge between the browser and the balancing robot, so I'll just adapt it to communicate using the nrf24, and run it on Raspberry Pi. On the downside, my app is a twisted app, so I guess I'll have to write a twisted driver. I've connect the SPI pins as you would expect. CS0 is GPIO8 and it's connected to the NRF24 CS. I've connected GPIO24 to NRF24 IRQ. First thing I find is I need this library for SPI, Install it with pip: $ sudo pip install spidev A bit of compilation later, and I am ready to try some stuff: $ python Python 2.7.9 (default, Mar  8 2015, 00:52:26) [GCC 4.9.2] on li

Actually, if you search for nRF24L01+ arduino  you find a large entry in the Arduino playground . A little down the page is something that is not all that Arduino specific (although the examples are Arduino), or nRF24 specific: Radiohead . Sadly it doesn't support CC2500. It does seem like the nRF24 ecosystem is a great deal more vigorous than CC2500. Also, if I have to have a bridge to the PC, I could use a Bluetooth master and slave module - it's not like Linux would be a problem then, and as a bonus, I could still use a mobile phone as a controller. I've got some nRF24 devices on the way, but I also have some Bluetooth modules in older projects. Perhaps one of them supports master mode. I've also discovered a few variants of the nRF24: the nRF24LU1 and nRF24LE1 which include an 8051 micro controller and executable flash, with 4K RAM+USB and 1K RAM respectively. These can be programmed via SPI . I've exported the aforementioned to Github . Although you get a

I took my balancing robot into the office today, plugged a USB wifi dongle into my computer. I connected to the ESP8266 in AP mode. Sadly, it didn't work so well: the connection dropped regularly, about one in 3 packets got dropped, and the buffer overrun problem I previously thought only applied to TCP packets started happening to UDP: the tails of previous packets getting included at the end of new ones. OK - so I've eliminated Bluetooth completely because Linux is too crap at it. I've pretty much ruled out WiFi as too expensive, or too poorly implemented on the embedded side. What's left? Well, I have two CC2500 modules. On the embedded side, the SPI interface is fairly (very?) convenient. On a PC or a phone, not so much, although I could stick one in a box with a micro controller to get something usable for a pc. There's also the  nRF24L01+ which there are also cheap USB adapters for. The breakout boards seem to be available for £1, so it's probably w

I finally got around to tuning the new balancing robot a few days ago. It didn't go very well: I set KP and moved onto KI, but it started simply to fall over. Then I realised the battery was starting to drain: that was the problem. The charge had just leaked out over a week or so. I'd actually anticipated this, and added a little divider network to the motor board, to let me test the battery with an ADC, so I decided to add the required code. The resulting commit is here . There are a lot of choices when doing ADC conversion in the STM32F4: If you want to sample as fast as the device can go, you can collect the data with a callback. You could also trigger conversions periodically, using a general purpose timer. Both of these require hardware resource assignment: Owning the ADC device, and also a general purpose timer in the second case. The STM32F411 only has one ADC, although it's pretty fast and can cycle through 16 channels. It's also a bit quirky though: You c