nRF5 action!

[Omemanti]

@neverdie well, July 2017 they were €4,15. So they went up around 1 euro in a year. FYI the last one I bought was about 5 months ago since then they went up from version 1,1 to 1,3.
Also, the item number changed a bit (but the datasheet checks out).
It went from E73-2G4M04S to E73-2G4M04S1B, and the introduced a nrf52810 E73-2G4M04S1A with the same footprint and pinout.

[NeverDie]

@omemanti Ah, yes, you're right. It was on March 7, 2018 that they were on sale for $2.55.

Well, regardless, it's a good price. :)

[Nca78]

@omemanti the A version is with NRF52810, be careful.

[smilvert]

@neverdie Sorry, im a bit confused.

If im are going to use the BT832 for a battery sensor do I need to connet a 32 khz crystal like you did on the 10+ years wireless PIR Sensor (on just one set of 3 AA's!) project? But you have also written:
@neverdie said in nRF5 action!:

@alowhum IIRC, the crystal oscillator is only required by Bluetooth. For everything else, the internal resonator is sufficient.

How much more current are used if the crystal is not connected?

Can I use P00/P01 as a data pin instead of using the crystal?

[NeverDie]

You don't need the crystal. Not sure difference in current. Yes, to your last question.

[Omemanti]

@nca78 yeah I noticed that, what is the downside of the NRF52810?

[Nca78]

@omemanti said in nRF5 action!:

@nca78 yeah I noticed that, what is the downside of the NRF52810?

At least lower memory (ram and flash) and I don't know for the peripherals. Not sure if the core for nrf52832 will work flawlessly or not. Given the tiny price difference it's better to stick to nrf52832.

Low frequency crystal will make you save energy when you use Bluetooth, because it needs to wake up at precise time frames to send/receive data. Do in that case the internal oscillator is not precise enough and mcu has to wake up regularly to recalibrate it with high frequency clock.
For MySensors, it's not useful.

[Jokgi]

@nca78 There is no downside to using the nRF52810. It depends on your needs. If you can live with 192K Flash and 24K RAM and a stack that supports peripheral only (at this time) then you are good. The device can use the internal 32Khz RC osc for BTLE and there is a slight current consumption hit as the receive window will be longer. (+/- 500ppm) . No different then on the nRF52832. as stated, a 32Khz crystal will give you a tighter clock and lower current consumption.

This is a scaled down version of the nRF52832 so there are some peripherals that have been taken out or reduced. PWM for example, only one. No NFC, 1x SPI Master or Slave, (instead of 3), No I2s...... The full datasheet and product briefs are available on Nordic's website so you can A-B the features.

[Jokgi]

This post is deleted!

[NeverDie]

An amusing video, which nonetheless suggests the power of tapping into existing bluetooth devices:

https://www.youtube.com/watch?v=bS1tPp2-l2w

[Omemanti]

What are the options of getting OTA working? Is it supported? Or is it still work in progress? (If so, ia there an ETA?)

[NeverDie]

@omemanti said in nRF5 action!:

What are the options of getting OTA working? Is it supported? Or is it still work in progress? (If so, ia there an ETA?)

https://devzone.nordicsemi.com/f/nordic-q-a/38936/is-there-an-easier-to-use-ota-firmware-uploader

[NeverDie]

These are a bit cheaper than the Ebyte modules, and the breakout board is already built-in: https://www.aliexpress.com/item/NRF52832-Bluetooth-Module-BLE-4-2-Low-Power-Bluetooth-External-Antenna-IPEX-Support-Multi-Protocol/32904197412.html?spm=2114.search0104.3.102.772c16a3Fm2Lp8&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10130_10547_10546_10059_10884_10548_315_10545_10887_10696_100031_10084_531_10083_10103_10618_10307_449,searchweb201603_60,ppcSwitch_0&algo_expid=f8654a20-dd6e-4042-987f-5bd9eaf3c58d-15&algo_pvid=f8654a20-dd6e-4042-987f-5bd9eaf3c58d&transAbTest=ae803_4&priceBeautifyAB=0

[Jokgi]

@neverdie And it has the 32Khz crystal on it too which will reduce power consumption. And It looks like the DC/DC converter is also included?

[Toyman]

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

[Toyman]

@neverdie I've setup the bootloader for my BT project and I confirm its much easier than it looks.
Can it be used for MySensors? For BT, I create a hex file in Keil and then upload it via nrftoolbox app.
Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

[scalz]

@toyman said in nRF5 action!:

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

yes but you need some power buffer for the spikes. So put 100uF low leakage ceramic capa close to batt holder, and you could also add one more close to your nrf5 module.

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

You already have your answer I think ;)

[NeverDie]

@toyman said in nRF5 action!:

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

Ouch. :astonished: That does seem like a gotcha. :confounded: Thanks for pointing that out!

Let's enumerate the possible remedies: :thinking_face:

1. I guess theoretically the bootloader could use softdevice to handle uploads and then revert to MySensors afterward. After all, with these devices there's so much flash and memory that there's nothing which says the bootloader needs to be tiny. In that case your code would need to force a reboot, and the bootloader would need to wait a period of time to see if an OTA upload is being requested before continuing. But this is all theoretical, and I don't know enough to know whether that would be easy or difficult to make work. Far from elegant to be sure. Maybe there's a better solution than that? Admittedly, this looks like a rabbit hole I'd rather not go down.

2. Maybe (?) micropython is the the easier path out of this train wreck, assuming (?) it can assemble a string that it reads from OTA and then execute it (EVAL it) the way that. say, LISP, can. Then you could bypass softdevice entirely and use whatever radio communications you want. The relative ease of that might make it worth the added baggage of running an interpreter. Well, that might work for me, but for mysensors it would mean a major port to micropython, which, AFAIK, no one has yet done.

3. That leaves writing your own wireless bootloader, like I guess others here have done for mysensors and the atmega328p, but that doesn't sound trivial either.

4. Any other ideas?

I'm just thinking out loud here and above, but I'm admittedly now both stymied and flummoxed. Being wireless without the ability to do wireless updates is not good.

@scalz Does the TI platform have the same sort of issue, or does it handle OTA updates differently?

[NeverDie]

For instance, this buttonless approach stays in DFU mode for 30 seconds after a reset: https://thingtype.com/blog/dfu-ota-updating-an-nrf52-application-over-the-air/

I guess maybe that's the shortest path out of this dilemma.

[monte]

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.