@nrf24_is_hard When I sent data between an Aduino and the RPi I discovered that I have to make the the receiving and the sending structs the same size AND the variables be on 4 byte boundaries. Change your char name[15] to char name[16]
Another challenge is that the number of bytes of type int are different. If I remember correctly, Arduino Uno is 2 bytes and RPi is 4 bytes.
To make matters worse, some compilers make the least significant byte the first byte of a word and others make it the last byte of a word. eg, sending the value 1 would be received as 16777216 (0x00000001 vs 0x01000000)
There are a lot more gotcha's
OSD
@mfalkvidd Please keep us informed on how this goes for you.
A few months ago I also implemented a zigbee network for similar reasons. The nodes are very inexpensive, small, and coin cell powered. I am using these for common applications like temp or motion. That way I can use MySensors nodes for the more custom or complicated applications. So far I have had no problems, actually am surprised at how reliable and fast it is. I have tried to limit the number of different vendors as I understand that can present a problem. I opted to use ZHA (Home Assistant) instead of MQTT, so far works great. Using Sonoff USB 3.0, all other Sonoff zigbee nodes, Sengled bulbs, and Aqara cube, vibration & water detectors. If I run into any problems will also post here.
[Using Home Assistant, Intel NUC, Zwave, MySensors 2.4 & 915, Zigbee, ESP]
@NeverDie Yea, I think I knew you upversioned the silkscreen. I think I remember you commenting on it. Looks pretty. BUT in my effort to add to the community, since I typed it for my self for my V001 boards, I thought I'd share it incase there is anybody like me with V001.
I like the V003 upgrades, specially that reset bypass via as discussed with @alphaHotel . Maybe I'll try it. I've got so much into my little V001's (yours actually) that I just can't give-em up. When I get the boards rigged up with radios, GPS (on the USART bus) and SD Card reader (on the SPI bus with a different CS), I'll shoot and send a picture in the spirit of a party!
I just remembered the key technique to getting the communications working smoothly.
I do all my communication synchronously. That is as follows:
The master device sends a message to a node. The send command returns a success or fail, but fail does not mean the message was not received, it means that an ACK was not received. The master waits a timeout period for a response. If there is no response, a second attempt is made. If there is a response, the data with the response is processed. If not, the node is ignored.
After that transaction, the master repeats this process with the next node and for each node there after. A round-robin.
If a node does not get a request from the master within a certain interval, it reboots itself.
If the system power cycles, the nodes inundate the the master with DHCP requests. Because of so many requests, requests can be ignored or two nodes might receive the same network address (different from NodeID). Eventually, one node will get a valid network address and begin to communicate as expected. This reduces the network traffic and the probability of another node receiving a unique network address improves. Eventually, all nodes connect. "Eventually" can be many, many minutes.
The tree structure of the network means that some nodes send data through other nodes. In asynchronous communication, a node may be trying to send data while another node is sending data through it. I may not be correct in this, but I think that it is possible that this will corrupt one or both data packets. This is why I do the round-robin communication.
The master only has 5 (4?) usable addresses to receive data. Like computer DHCP, addresses can be reserved for specific NodeID's. For example, address 3 an be reserved for NodeID 31, then NodeID 22 can have a reserved address of 43, thus NodeID 22 will always send data through NodeID 31. (addresses are octal). The address 4444 is reserved; this is the address a node requesting an address uses.
To increase the chance of getting a valid address, I put a delay in the first DHCP request based upon the NodeID.
I put the NodeID in EEPROM address 0, as does MySensors. I have one program that sets the NodeID and then my program for all of my nodes is the same.
Nodes that sleep must have the flag set (in the node software) that indicates no data can be passed through it from another node.
All of these hoops are handled by the MySensors libraries, though I force the NodeID. This my impetus to use MySensors. I must wonder though, "How much overhead is there? Do I have enough memory for my code?" So far I haven't had a problem.
OSD
Small update. I switched to a radio from different batch and seemed like that fixed it. Saw the smart sleep message in mqtt until I went to bed. But around 4:30am it stopped again. Im going to go pull it again and see what it's outputting. I feel like I need to hook up a bluetooth hc-05 or something so i can just connect over bluetooth at this point to get the serial data lol
I made this CR2032 coincell powered locator beacon using an nRF52805:
It was my first experience using a TAG-CONNECT to make the programming connections. It's for that reason that I haven't yet attached the battery holder. The TAG-CONNEC provides power during programming (and debugging as well if so desired).
I have the antenna hanging out over the edge, as per Nordic Semiconductor recommendations, so that it doesn't hover over the ground plane. However, that makes the overall footprint a bit larger, somewhat defeating the point of powering it with a CR2032. I may try making a smaller version where the antenna doesn't overhang just to see how much difference it does or doesn't make. For a device like this, I mostly care about reception rather than transmitting, so maybe for receiving such a change won't make much of a difference.
Who makes the world's smallest nRF5x module?
@NeverDie said in Bootloading a barebones arduino:
You and a group of friends could sit around a table and pass bits and bytes to each other using an SPI communication protocol.
Passing bits and bytes is probably more fun that sitting around a table and passing digs and barbs! I don't know: maybe my friends ARE binary!
[Edit: I forgot to say anything about the content of your SPI protocol story. That was a great story; I feel badly for not thinking about the SPI connection at all. Now it is ingrained. ]
