nRF5 action!
-
Dang, I just noticed that this board has a FEMALE ipx connector on it:
https://www.aliexpress.com/store/product/1pcs-NRF52832-Bluetooth-module-M4-kernel-Bluetooth-4-1BLE-module/2629039_32821473149.html
At least the Ebyte module has a male ipx on it, which seems much more common. -
@Jokgi said in nRF5 Bluetooth action!:
I believe that the Notwired price you mentioned was for the full dev kit board with RF module.
I wish that were so, but it just doesn't look that way to me. It seems that the dev board that could go with it is sold separately, and is another $95:
https://www.notwired.co/ProductDetail/CWSEPARD-notWired-co/606027/ -
@Uhrheber said in nRF5 Bluetooth action!:
I just received 2 of those little boards.
Ideal for small sensor nodes, I'd say, but not very breadboard friendly.
So I dug out the verowire, and did a little soldering.
Looks as though the module itself is missing the SW pinouts. Is that what the two wires you soldered near the chip are for?
-
So, I just did what NCA78 inspired me to do: resoldered the capacitor to enable the IPX connector. The results? It is an improvement, and I can see the difference at the margin, but still nothing like the 20dbi of the amplified modules. Not surprising. So, I guess I'll try to find one of those as either an nRF52832 or an nRF51822, and give that a try.
@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup. -
@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup.@Uhrheber said in nRF5 Bluetooth action!:
@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup.I used an antenna that I temorarily removed from an ASUS router. I don't know what it's gain is supposed to be. However, I had similar thoughts, so yesterday I ordered this from amazon:
https://www.amazon.com/gp/product/B073SWWMRG/ref=od_aui_detailpages00?ie=UTF8&psc=1
which claims a 9db gain. It should arrive tomorrow. It's not really ideal, because it has to go through three connections (first the IPX connection and then an SMA connection and then finally the antenna connection), whereas it would be preferable to just have one connection so as to have less insertion loss. I'd be interested if you have any suggestions for something even better. -
@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup. -
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings. To that end, looking at Figure 30: On-air packet layout in the datasheet (http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.3.pdf), that would mean eliminating CRC, SO, LENGTH, S1, and the payload. What's left? Just an address. I could use one logical address to mean "ON", and a different logical address to mean "OFF".
I had already eliminated CRC from the radiohead code, and it all worked fine. Now I'm converting over to the MySensors transport code, and I'm wondering: how should I approach getting rid of those extra bytes using the MySensors transport code as the starting point?
-
I've had success in changing from sending one byte of payload to no payload at all by changing from
NRF_RADIO->PCNF0=0x80108to
NRF_RADIO->PCNF0=0x80008However, so far I haven't been able to shed S0 and/or S1 and still get the packet received, even if there's no payload.
Interestingly enough, the smaller frame works better than the more bloated frame. I guess less chances for it to get corrupted over the air.
-
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings. To that end, looking at Figure 30: On-air packet layout in the datasheet (http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.3.pdf), that would mean eliminating CRC, SO, LENGTH, S1, and the payload. What's left? Just an address. I could use one logical address to mean "ON", and a different logical address to mean "OFF".
I had already eliminated CRC from the radiohead code, and it all worked fine. Now I'm converting over to the MySensors transport code, and I'm wondering: how should I approach getting rid of those extra bytes using the MySensors transport code as the starting point?
@NeverDie said in nRF5 Bluetooth action!:
@d00616
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings.I think the best way to do this is using the Bit counter. Set a timer to stop the radio and with the bitcounter, you can stop this timer. With the BC, you don't loose the CRC or length information. The Bit counter counts the S0/S1 and Length information and all data bits.
I use the bitcounter in the ESB-TX mode.
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings.I think the best way to do this is using the Bit counter. Set a timer to stop the radio and with the bitcounter, you can stop this timer. With the BC, you don't loose the CRC or length information. The Bit counter counts the S0/S1 and Length information and all data bits.
I use the bitcounter in the ESB-TX mode.
Since it appears now that there's no way to avoid sending S0, LENGTH, and S1 over-the-air in the course of a full packet transmission cycle (even if their values are zero), I'm having success using EVENTS_ADDRESS to remove them from the equation anyway by cutting short the full packet sending/receiving process just after the address is either sent or received. :)
-
I received the following message from the Ebyte seller:
Sorry that the two files are incorrect, please just ignore or delete them. We will send correct files later. Thank you!@NeverDie said in nRF5 Bluetooth action!:
I received the following message from the Ebyte seller:
Sorry that the two files are incorrect, please just ignore or delete them. We will send correct files later. Thank you!Hi, they sent you the right files? Can you share them?
Thank you very much, great discussion
-
@NeverDie said in nRF5 Bluetooth action!:
I received the following message from the Ebyte seller:
Sorry that the two files are incorrect, please just ignore or delete them. We will send correct files later. Thank you!Hi, they sent you the right files? Can you share them?
Thank you very much, great discussion
-
OK, so I've reduced the over-the-air transmission to one preamble byte and 5 address bytes, for a total of six bytes. The transmitter sends a packet to a different logical address depending on which button is pressed, and the receiver can determine which button was pressed depending on which logical address matches.
So far, so good. The question now will be how many of those bytes I can eliminate before I start to get garbage packets.
The other factor is the granularity of the RTC. The receive window will either be about 30us or 60us, and I believe (but haven't yet confirmed) that I'm already at around 60us. So, I may already be at the practical limit.
-
OK, so I've reduced the over-the-air transmission to one preamble byte and 5 address bytes, for a total of six bytes. The transmitter sends a packet to a different logical address depending on which button is pressed, and the receiver can determine which button was pressed depending on which logical address matches.
So far, so good. The question now will be how many of those bytes I can eliminate before I start to get garbage packets.
The other factor is the granularity of the RTC. The receive window will either be about 30us or 60us, and I believe (but haven't yet confirmed) that I'm already at around 60us. So, I may already be at the practical limit.
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings.I think the best way to do this is using the Bit counter. Set a timer to stop the radio and with the bitcounter, you can stop this timer. With the BC, you don't loose the CRC or length information. The Bit counter counts the S0/S1 and Length information and all data bits.
I use the bitcounter in the ESB-TX mode.
@d00616 You may wish to count your retries as well. It is no use keeping the window narrow if you need to keep transmitting and receiving to get the same packet across. It may show that having a little wider window reduces the average current required by increasing the chance of picking up the packet first time. If you are using a timer to synchronize the RX and TX (TDMA) then you may be just fine.
-
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
According to the datasheet, it appears to force a minimum of 3 address bytes anyway: 2 base address bytes plus 1 prefix address byte. With no prefix byte, it would appear that's as low as the hardware will allow.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.
According to the datasheet, it appears to force a minimum of 3 address bytes anyway: 2 base address bytes plus 1 prefix address byte. With no prefix byte, it would appear that's as low as the hardware will allow.
-
I can't make sense of the Packet configuration register 1 (PCNF1). Upon powering up, its value reads 0x262164, which doesn't really make any sense. I then try changing it to 0x22164. When i re-read it though, its value is then 0x139620, which is completely different. And this is 100% repeatable.I can't make sense of this. What's going on with PCNF1? Why doesn't it keep the value that I set it to? why does it rapidly change over to the other number, and why that number in particular? I've tried setting it to other numbers also, but each time it doesn't stick and instead produces a puzzling number in its place. I've even confirmed that the radio is in a DISABLED state prior to making the change, but that doesn't seem to help either.[Edit: mystery solved. I was accidently printing it as decimal instead of HEX. So, it works perfectly after all. :)].
. -
Setting aside that mystery for the moment, the remote control presently is working very well, and the current draw during listen mode is now down to this:
which is certainly less than previously. Scale: 1mv=1ma.It turns out that there's a minimum of 1 preamble byte. So, all told, there is a minimum of 4 bytes total that have to be transmitted: 1 preamble, 2 base address, 1 address prefix.
Eyeballing it, it does look as though the actual window of active listening is already around 30us, and unfortunately the granularity of the RTC prevents me from making it smaller than that. So, I suspect that, regarding power draw, this is already as good as it's possible to get. :)
-
Setting aside that mystery for the moment, the remote control presently is working very well, and the current draw during listen mode is now down to this:
which is certainly less than previously. Scale: 1mv=1ma.It turns out that there's a minimum of 1 preamble byte. So, all told, there is a minimum of 4 bytes total that have to be transmitted: 1 preamble, 2 base address, 1 address prefix.
Eyeballing it, it does look as though the actual window of active listening is already around 30us, and unfortunately the granularity of the RTC prevents me from making it smaller than that. So, I suspect that, regarding power draw, this is already as good as it's possible to get. :)
@NeverDie I would use 3 ADDRESS bytes, for the reason I gave before. The receiver could see noise as a valid packet and try to process it. and the fact you have no data packet and no CRC could cause you issues in a noisy 2.4Ghz environment. . Also be aware that if the radio is not already in receive or transmit mode the PLL takes about 130us to come up and settle. Crystal start and settle time will also depend on the CL value of the Crystal and not all manufactures use the same value. Conversely you can only transmit packets for 4ms before you need to bring down the transmitter and bring it back up again for the PLL to start and settle.
