Little bits of progress on NRF24

It's been so long since I posted about this I had to go back and look at what I'd last written. I've covered a lot of territory.

Recently, the NRF24L01+ driver I'm using has proved problematic, as has the data sheet itself: It doesn't make it clear if FLUSH_TX or FLUSH_RX delete all the contents of a fifo, or just the next item.

From this in the product specification, you might think just the next item:
Note: Always check if the packet width reported is 32 bytes or shorter when using the
R_RX_PL_WID command. If its width is longer than 32 bytes then the packet contains errors and must be discarded. Discard the packet by using the Flush_RX command.
Otherwise it's a bit ridiculous: why would you discard valid packets from the receive buffer to get rid of one invalid packet at the head? Actually FLUSH_RX does flush everything. Why would you suggest that when you can discard a single packet by just aborting an R_RX_PAYLOAD? There are perhaps a reason for this: dumb SPI implementation (e.g. Linux) might not deselect (raise CS) to reliably abort the transaction.

deselecting does seem to abort the transaction - and that's how I've dealt with it.

Actually, why is this a special case at all? Why doesn't the packet just get discarded? I guess it was deemed wildly improbably it would ever happen, until someone noticed it happen.

The driver's getDynamicPayloadSize() has this horror in it:
  if(result > 32) { flush_rx(); delay(2); return 0; }
  return result;
Which means you can't tell from the return result if the FLUSH_RX has occurred or not. That R_RX_PL_WID can return 0 seems to have been ignored, but I've seen it happen, and of course it just leaves you in a loop trying to read the packet - the length is zero, so you skip the read, but it isn't flushed.

Popular posts from this blog

3D Printer ramblings

 I have a Prusa i3 mk2.5 in storage. I used to use it in my shed I used not to worry about it's harmful emissions: I just didn't share the space with it. I had, however, added an enclosure, and was planning to add a HEPA filter too it. Once it's in an enclosure, it's massive. Even if I had added the filter, there's no where to put it. I'd like a small printer that has an enclosure or is easy to enclose. I figure I could get by with 150x150x150 build area: I was rarely patient enough to wait for my i3 to print bigger models. 200x200x200 would probably actually replace my current printer, so that would be a bonus. Not many printers have HEPA filters, which is really a shame. It seems just to be the result of a misconception about HEPA filters, and about filtration in general. Read this . E.g. I was looking at a used Lulzbot mini, and there are ready made enclosure s for it, however . In this particular case, it's no big deal: opportunities to buy a Lulzbot min
Read more

Balance Bot V2

Image
My current balance bot sort of works, but it's surprising it does: it's centre of gravity is actually only about 60mm above the motor axis. The whole thing ways 320g. The 6 AAA batteries only weigh 70g, so despite being right at the top, the don't affect the centre of gravity much. 6 AA batteries would weigh about 180g. That would add a 34% to the overall weight, and move the centre of gravity much higher. Seems like a dramatic increase in weight: it would be nice to be a bit more incremental. More AAA batteries isn't really worth considering: they only weight 12g, vs 30g for an AA. 4 AA would deliver much less power/torque, so that's no good. There's no middle ground, in other words. I'm also going to make the whole thing a bit taller: I need more space to add more sensors in any case. Last time I made the frame, I needed an elaborate jig to get it square and it actually didn't work that well. This time, I decided to use some short bits of a
Read more

Robot arm

Image
I 3d printed this robot arm I original found on Thingiverse, but the Instructable is recommended. There's a MK2, and also a delta style arm, both of which look like good alternatives, but this will do for now. Here's a video of it moving: I've attached it to an STM32F4 Nucleo board, via a prototype shield: In the video, I'm sending commands from a python script that runs on my desktop, communicating via USB serial. I've written an implementation of canonical s-expressions in c++ that doesn't require memory allocation, as well as a python version to talk to it. It's the main reason I haven't posted for so long, and of course overkill for just controlling some servos, but should prove more generally useful. Here's the code . It uses platformio for the build, and mbed rtos.
Read more