• nRF24L01+ Basic Smoke Testing

    ziggurat29 • 07/08/2018 at 17:21 • 0 comments

    Summary

    Simple low-level tests of the nRF24L01+ module on the 'Blue Pill' STM32F103 board were performed to validate that the uC peripherals were configured correctly, and that the attached radio is responding as expected.

    Deets

    Since I had more-or-less decided on using the low-cost Nordic Simiconductor nRF24L01+ radio, and the 'Blue Pill' STM32F103 board, the first step was validating that the hardware combination was working OK.  This meant setting up SPI, and communicating with the radio in some trivial way.  This in turn meant understanding the registers, etc., at least a little.

    Before setting out writing my own 'driver' for the radio, I did a little research for existing ones.  This radio is not new, and is quite popular, so surely there is a plenitude of useable stuff out there.

    I found several candidates, but ultimately liked the one from 'LonelyWolf' the most:
    https://github.com/LonelyWolf/stm32/tree/master/nrf24l01
    for a few reasons:
    • it is fairly minimal and stand-alone, and so didn't incur too much dependency hoisting
    • it has a well-defined partition between the board specific stuff (for SPI, interrupts, chip selects) and the chip-specific stuff (functions for writing registers, etc.)
    • if nothing else, it saves my the transcription of all the relevant constants, etc., from the datasheet

    That being said, it is not 'perfect' for my needs, so I will be altering it a bit.  In particular:

    • the division between the board-specific stuff and chip-specific stuff strikes me as imperfect, because for example the chip-specific stuff presumes the existence of a single-byte-wise SPI transaction, and multi-byte transfers are synthesized from that in the chip-specific layer
    • somewhat related, the lack of multi-byte transfers in the board-specific layer obviates the utility of interrupt- and dma- driven SPI operations, since as defined they are just single-byte
    • there is no provision for chip generated IRQs; i.e., as implemented, handling of chip events (e.g. rx data available, tx completed, error) must be done in a polled mode in protocol layer code (there isn't really any protocol layer code in the library, per se; any 'protocol' is simple point-to-point operations made in the demo code in main())

    So, there will be some factoring down of the multi-byte transfer code into the board-specific layer to faciliate interrupt and dma driven IO, and some IRQ provision once I concoct an architecture for that.

    Also, since I'm planning to have DMA and IRQ support, I'm goign to implement a packet buffer pool that the 'protocol' layer will be using (i.e. 'getBuffer()', 'returnBuffer()', etc.), and this design may have some impact on the existing PAI definitions.  It's too early to know yet, since I'm still learning the chip.

    In the meantime, I did get the extracted code (just two implementation files, and headers) integrated, and I did manage to verify trivial SPI communications with the chip.  I used the same method LonelyWolf's library used:  set the chip address, read it back, and validate that the setting stuck.  So SPI to the chip seems to be validated; yay!

    Now, I need to do the rest of the factoring I mentioned above so that I can move onto considering the for that the protocol layer will take.

    Next

    Continue factoring existing library code and making needed modifications.

  • Research

    ziggurat29 • 06/13/2018 at 00:23 • 0 comments

    Summary

    Some research was done into existing projects.  It's still not clear if I should attempt my own twist on a mesh networking protocol intended for mosh pits.

    I am setting up for experiments with the nRF24L01+ modules, and 'Blue Pill' STM32F103 boards.

    Deets

    I did some initial cursory research.  As expected, simply doing a web search on 'nrf24l01 mesh' yielded many existing projects, libraries, and other sundry mish-mash of mesh.  Some standouts:

    Home Smart Mesh - Hackaday.io
    https://hackaday.io/project/20388-home-smart-mesh
    https://www.homesmartmesh.com/mesh/

    This looks like a very high-quality project.  Maybe it will obviate my doing any work, but I need to review it more.  It seems to be oriented towards being able to deploy nodes in an ad-hoc manner around the house, and have a self-organizing mesh evolve from that.  That's great!  However it does also seem to be designed for more-or-less fixed placement of nodes, rather than rapidly moving (which is fine for it's design intent), so I should look to see if that is an issue.  I'll probably have to build it and try it out to know for certain.  Also, it seems to be designed for a reasonable number of node for a home mesh -- 255 max, which is too low for my application.  Maybe that's adjustable somehow.  Lastly, there are distinct roles that nodes play, with routers and non-routers.  This is quite common in mesh networks, but I was hoping to have the various nodes be a strictly peer-to-peer implementation.

    Still, it looks like a greate project, and I will have to kick the tires with the firmware, regardless if I wind up using it in this application.

    RF24Mesh- Mesh Networking Layer for RF24 Radios
    http://tmrh20.github.io/RF24Mesh/

    This is a library/project specifically for nRF24L01+ devices.  It looks pretty stable.  It involves a 'node' for tracking address assignment, which doesn't fill my heart with joy.  Also, there is a 255 node limit.  Still, the code is worth a look, I think.  There will be something to learn, I'm sure.

    B.A.T.M.A.N. protocol concept
    https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept

    While researching some general mesh routing topics, I came across an experimental protocol named B.A.T.M.A.N.  Some things which caught my eye were the motivation to distribute the routing information in sub-graphs, rather than having a full topology graph stored anywhere.  I think this sort of thing will be important for handling rapid local topology changes that are expected in the mosh pit.

    This protocol is intended for use over IP and UDP, and talks about 'small packets' of 52 bytes, which is larger than the absolute maximum packet size of the nRF24L01+, so regardless of what it is, it will need some modification.  Still, it seems worth further study.

    In a more general sense, I came across several academic publications about current mesh routing algorithms, so I will need to familiarize myself with all of those, and their relative strengths and weaknesses.  E.g.

    https://pdfs.semanticscholar.org/f840/813413c48f7caf3c9e9b229e964ddfe3d77e.pdf
    A Survey on Routing Algorithms and Routing Metrics for Wireless Mesh Networks

    OK, coming out of the library with my eyes glazed over, I needed a little break with some hardware.  Regardless of what I'm going to do, I still need to have a board with a radio on it for experiments.

    I did discover that I have 14 nRF24L01+ modules laying around.  I've never used them before.  I bought them on a whim thinking they might be useful someday, and I guess today was that day.

    I need to have something to drive them, though.  I have a pile of boards, but for this project I thought that I might use the "Blue Pill" STM32F103C8T6-based board.  I have 4 of those on-hand.  They don't have honking RAM/Flash, or particularly exotic peripherals, but since this is a research project focused on...

    Read more »

  • Mosh Nyetworking -- The Feeling Begins....

    ziggurat29 • 06/10/2018 at 19:17 • 0 comments

    Summary

    This project is to give me a sandbox platform for developing/experimenting with mesh networking.  In particular, the goal is to end up with an uber-cheap, rapidly self-healing, zero-configuration mesh network that is intended to operate in spatially dense physical setting.

    Deets

    In a discussion with some folks on an unrelated topic, I had a stray thought regarding enabling the project with networking capability.  Because that project was intended to be a semi-disposable semi-novelty item, I wanted it to be:

    • uber cheap
    • requiring zero configuration
    • able to function effectively with a large number of nodes in close physical proximity.  'Large' equals around 10k min, I think.  'Close' means around 1000 units in a 10x10x10 volume, I think.
    • be able to self-organize effectively when the physical relationships between the nodes were frequently and perhaps rapidly changing

    I have long been enthusiastic about mesh networking, and years ago had considered designing in some ZigBee modules.  It was as IIoT project for a commercial client, so the cost of the ZigBee modules was not much of an issue.  It used GSM networking to the Internet, but I was hoping to have the site specific networking to be done via mesh, and just have one device effectively be the 'gateway' for the entire site.  In the end, the client didn't care if every node has a GSM modem in it, so we didn't go the ZigBee route, and now I have a little sack of ZigBees waiting for the day they will swarm forth again.  But today will not be that day.  They're too expensive, and I think they are more intended for ad-hoc networks of semi-stationary nodes.

    My first idea was to do InfraRed, but I quickly withdrew from that thinking because I suspected that line-of-site will be a bit awkward to maintain in a rapidly moving environment.  So my thoughts then turned to radio.  There are some stunningly inexpensive radio modules out there, and I thought I remembered I had a sack of Nordic nRF24L01 modules that I had never used.  Those cost USD $1 each, so definitely fit in with the cost objective.  If I can use them.  But that's my first hypothesis.

    Like any project, it behooves one to do some research first.  If this has already been done, then why don't I avail myself to that existing work, instead of re-inventing (and quite possibly poorly) the same functional thing.  I have a feeling there are a cornucopia of mesh networking projects out there, and maybe even many for the nRF42L01 specifically, since it is such a popular module.

    Another task is deciding whether and when to publish the project.  In some ways, I'd rather do the feasibility study off-line first.  If the project just winds up finding something that already exists, then that's the end of the project, and there's not much to report.  On the other hand, if I don't start creating logs immediately, then I'll lose some history and the project documentation will have a sterile, pre-fabricated feel to it, as if it was first born into complete and correct implementation, which as we know projects to not actually evolve that way.  At least not interesting ones.

    Another vitally critical task to which one must immediately attend is to come up with a project name -- ideally with a corny pun.  Because this notional mesh network is intended to be used in a potentially densely populated and changing physical arrangement, this evoked in my mind a 'mosh pit' at a concert.  So it was definitely going to be 'mosh networking'.  Because one pun is not enough, I punned 'nyetworking', because...  Well, I don't really know why other than that I was craving a pun.  Maybe I'll wind up jinxing myself with that one, but I suppose I can change it later.  So, it is hereby dubbed 'Mosh Nyetworking' until such time as I grow weary of it.

    The next most vitally critical task is to have a nifty...

    Read more »