nRF5 action!

[NeverDie]

Not sure if this thing would work, but maybe?
https://www.amazon.com/gp/product/B01B94U438/ref=od_aui_detailpages00?ie=UTF8&psc=1

[Jokgi]

@NeverDie This module is based on the nRF52832 and a RF AXIS PA (now purchased by Skyworks) . I happen to have one of the first prototypes. This design worked great! . Note the blue wires attached to the 32khz crystal which was later mounted on the board.. Laughing a bit here. .

[Jokgi]

@NeverDie I believe that the Notwired price you mentioned was for the full dev kit board with RF module.
The Octotech device is not out in the market yet. I don't think they will be making production modules. Probably will have dev kits and then looking for module manufactures to produce modules with their part. 0_1507066567924_8TR8210 Product Brief RevA3.2.pdf

[NeverDie]

@Jokgi said in nRF5 Bluetooth action!:

This module is based on the nRF52832 and a RF AXIS PA (now purchased by Skyworks) .

Cool! Anyone selling it now besides Aliexpress?

[NeverDie]

@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/

[NeverDie]

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]

@NeverDie If that is the case then I kind of limits their clientele a bit.

[Uhrheber]

@NeverDie
Exactly. There are two pads labelled SWD and SWC, originally meant for pogo pins.
I patched them with wires to the pin header.
Programming with a Chinese STLink V2 clone works flawlessly.

[Uhrheber]

@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]

@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]

@Uhrheber said in nRF5 Bluetooth action!:

What antenna did you use?

Here's a photo of it:

[NeverDie]

@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. 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]

I've had success in changing from sending one byte of payload to no payload at all by changing from

NRF_RADIO->PCNF0=0x80108

to

NRF_RADIO->PCNF0=0x80008

However, 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.

[d00616]

@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]

@d00616

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. :)

[maniron]

@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]

@maniron
They never sent them. Would you be willing to try asking them too? Maybe if enough people do, they'll finally take some action.

Unrelated, but I notice they've raised their prices.

[NeverDie]

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.

[Jokgi]

@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]

@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.