Miniature wearable OLED display with 3.7v LiPo battery and nRF24L01+ data transceiver. It's working, but I'm having problems understanding the RF24 library.
By Julian
Youtuber, shed dweller, solar charge controller aficionado
Good morning all…
Youtuber, shed dweller, solar charge controller aficionado
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Julian, I do not feel as bad now, I have had projects fail to. So you should not feel bad either!
Hello Jullian, i have watched your interesting projects and most of them uses that thin LCD screen. I tried finding but havent found one yet. can you please link that LCD and its specs pls.
what has beneath the 17043?
quick look that code is not make any sense to be 🙂 why need know on receiver part if data came rrhu when you see data .why is allways send 0 is. becouse when sending is succsefull it not send i[1] in that time becouse it send it on next loop and next loop fail it not send any and when you again sucesfully send it is sending i[0] becouse ast try was failed 🙂 .
Hi.
First, thank you for this beautiful project, second, if you can,please, tell me how you calculate the "battery life percentage".
Thank you for help, in advance
Perhaps it is not clever, but I would first swap the then/else parts of this IF. To be able to see that it is working correctly (start receiving 1s insted of 0s).
The receiver is probably not acking anything while it is updating the screen display. This would cause the sender to set a zero in the next packet, which is then displayed. Rather than displaying the id of the received packet, a much better idea would be to display the difference between the id of the previous packet. That would let you see how many packets were missed. My guess is, you would see it constantly displaying 2 (meaning one was missed).
Morning all – and thank you all for your suggestions. It's FIXED!! Update video coming soon.
Maybe the code of your reciever is wrong, and you need to send a "confirmation" back or something…
still very nice Project though, are you planing to design your own PCB to fit allt hese chips, or are you going to bodge all these off the shelf PCDs together in the end? 🙂
It looks like its transmitting correctly, communications systems are usually set up to avoid sending false data, they either work perfectly or they fail all together. Maybe there's something wrong with the "if(radio.write(i, sizeof(i))); statement?
Very good, and we'll paced video. Am definitely looking forward to the next one in the series!
Can you please enable setAutoAck and check how it works ? I am not sure if by default ACK is enabled. This may help to identify if the packet has been delivered or not.
Paremeters of setRetries has only two passing parameters uint8_t type which is only 8 bits wide. Max value can be 255 and you cant pass 1000 on that (it will get truncated to 1000 AND 255 = 232). I am not sure why arduino compiler has not raised any warning or error. I have never used arduino because I am a fan of PIC and STM32. However, documentation finally tells how big these number can be. Flow control of any wireless communication is a bit problematic when there is poor signal and you need to send a large chunk of data. It will be nice to slow down the transmission rate so that the counter increases one by one slowly to see in naked eyes and then do the experiments in poor signal condition if that increases correctly.
Hi Julian,
I haven't seen your receiver code yet, but do you have the addressing correctly setup? Even though you communicate through a pipe each node in such a pipe needs individual addresses for the auto ACK to work.
I guess that your receiver's rxPipe is set up correctly since your data ends up there. However if the receiving code does not where it should send its auto ACK package, it will never end up in your sender transceiver and it will just re-transmit until it fails.
in my code I always define both nodes in the code like this:
const uint64_t rx_pipe = 0xF0F0F0F0D2LL;
const uint64_t tx_pipe = 0xF0F0F0F0E1LL;
and on the receiver part I setup two pipes for the auto ACK to work:
radio.openWritingPipe(tx_pipe);
radio.openReadingPipe(1,rx_pipe);
It works perfectly for my modules…
I hope this can be of any help. You should see the nRF24L datasheet how this works. It can be somewhat confusing regarding the node addressing.
Best regards,
Bjorn Erik
FYI, 8 bit unsigned integers can't hold the number '1000', it's probably being converted to 232.
How about changing the write() into a loop that tries until it returns true? Count those retries and print that to the serial console.
I guess you've already tried this, but what happens when you simplify your code and only write raw TX and RX data to the console? Just a Serial.writeln, without updating the OLED.
What is being sent and what gets received?