-
Reliable low-range wireless-enabled MCU/hardware/stack suggestions
Posted by
uer166
on 24 May, 2022 04:06
-
I'm thinking about designing an own wireless remote for a e-skate type application as a learning exercise about wireless. I'm looking for something that has a relatively easy-to use wireless function (can be bidirectional or one-way only from remote to motor control MCU).
I have general embedded experience, but 0 knowledge about wireless stacks/hardware beyond the basics. It doesn't need to actually comply with any FCC regs since it's a one-off, but it does need to be quiet enough, and keep a low enough duty cycle to not jam anything or raise any eyebrows, and I suppose keep to the ISM bands.
The major requirement is it needs to be absolutely reliable with a ~10ft range (for brake function on steep SF hills), maybe with some form or frequency hopping, as simple as possible with few states (e.g. BLE is out of the question). A minor requirement is that the MCU/chip can also crunch enough numbers, and have enough PWM peripherals for a full FOC motor controller. It need not be any standard protocol, or inter-operate with anything else, both sides would be custom-designed.
Not interested in complete FCC-certified modules, need to be bare chips with ideally existing reference designs.
-
#1 Reply
Posted by
jeremy
on 24 May, 2022 05:01
-
-
#2 Reply
Posted by
uer166
on 24 May, 2022 05:16
-
I wonder if sub-GHz would have any advantage in test and layout, I've been looking at STM32WL and similar which have enough facilities for motor control and radio, but the tools only include Lora and Sigfox which seem to be more for long-range, low BW applications. Nordic's tools also seem much nicer for RF than ST..
-
#3 Reply
Posted by
jeremy
on 24 May, 2022 05:25
-
2.4GHz has the advantage of smaller antennas, and lots of options available.
I would not use LoRa for something like this as the on-air time is fairly long, but from what I recall the Semtech radios support raw FSK and GFSK too. Also keep in mind that (at least in AU), the legal maximum transmission duty cycle is a lot lower on 900MHz than 2.4GHz.
Also, have you tried to actually buy an STM32WL device?
At least the Nordic parts can still be found on aliexpress…
-
#4 Reply
Posted by
uer166
on 24 May, 2022 05:29
-
2.4GHz has the advantage of smaller antennas, and lots of options available.
I would not use LoRa for something like this as the on-air time is fairly long, but from what I recall the Semtech radios support raw FSK and GFSK too. Also keep in mind that (at least in AU), the legal maximum transmission duty cycle is a lot lower on 900MHz than 2.4GHz.
Also, have you tried to actually buy an STM32WL device? At least the Nordic parts can still be found on aliexpress…
Good points on the antenna size and duty cycles! Yeah they do support raw FSK, but I don't have it in me to figure out a good protocol/stack quite yet, which is why a nice canned solution like that Nordic one seem to be the best bet.
The STM parts seem to be (surprisingly?) somewhat available from major distributors:
https://www.mouser.com/ProductDetail/STMicroelectronics/STM32WL55JCI6?qs=DPoM0jnrROVj9ZL1d6pcUg%3D%3Dhttps://www.digikey.com/en/products/detail/STM32WL55CCU7/497-STM32WL55CCU7-ND/13557443
-
-
-
#6 Reply
Posted by
Siwastaja
on 24 May, 2022 06:41
-
I took chances with the nRF52 family, specifically Fanstel modules, but you can easily just use the nRF chip as is. Some key findings so far:
Hardware design and documentation is just excellent. This is the easiet-to-program (on register level!) MCU family I have ever used - including the RADIO peripheral!
As a massive contrast, the SDK / official software ecosystem is one of the most horrible, most complex jobs ever. Simplest of examples compile tens of thousands of LoC, and do not work out of box. You can't even get hello world, because hello world is printed using a custom NIH "logging library", which requires configuration (10kLoC configuration file) to work. I spent hours trying to fix the logging library and gave up.
In the end, I just needed radio comms (and had quite special custom requirements regarding timing and bandwidth), not compatibility with Bluetooth devices, so I did not use the Bluetooth stack at all. Went bare metal writing custom code for the RADIO peripheral.
I started with the Enhanced ShockBurst example - that was actually possible to compile and use, worked almost out of box. The next step was to modify ESB example, changing the radio into BLE 125kbps LR mode - it requires a few modifications. But do beware - ESB is nothing special, it's quite primitive. You can easily surpass it with your own protocol. For example, adding resends and frequency hopping greatly improved the performance over the ESB example.
For a simple one-off, you can go pretty far by something like this:
typedef struct __attribute__((packed))
{
uint8_t len;
union
{
own_payload_type1_t own_payload_type1;
uint8_t payload[250];
}
} packet_t; // remember to configure the packet structure in NRF_RADIO peripheral, so it automagically knows how wide len field is, maximum length of payload, etc.
packet_t packet;
packet_t.own_payload_type1 = {1,2,3,4,5};
packet.len = sizeof (own_payload_type1_t);
NRF_RADIO->FREQUENCY = 42; // 2442MHz
NRF_RADIO->PACKETPTR = &packet; // the peripheral understands the len field in memory, and uses DMA to send the packet. Quite neat.
NRF_RADIO->TXEN = 1;
// poll for NRF_RADIO->EVENTS_DISABLED, or make it an ISR
This example shows how easy this is to use!
Of course being who I am and preferring custom solutions, I ended up writing a full fancy protocol with pseudorandom/controllable frequency hopping, message buffering + resend requests, multi-slave timesharing etc. And I don't know if that made any sense, it took a couple of months in the end. But one thing is sure: the peripheral (HW) design and datasheet made the work much less painful than dealing with STM32, for example.
nRF52 devices also have decent PWM peripheral (seems to have 4 compare registers) so it should be able to drive a motor if you use external half-bridge gate drivers with deadtime generation. It seems the thing does not have internal deadtime / negated outputs.
But, regarding your reliability concern with braking - ISM bands is, by definition, out of question. You can't, and I can't stress this enough, by definition, build anything with delivery guarantee over ISM bands. This is because ISM is defined as frequency band not designed for communication; it's the band designed for interference from microwave ovens etc. The fact people started to communicate over a non-communication band tells an interesting story about the misery of political regulation, but that is what we need to live with.
The best you could do is send a lot of small packets, frequency hopping over the whole band, but the problem is, any other device is allowed to wipe out that entire band any time. Then you must rely on physical separation, but how much is enough, this is hard to say.
-
#7 Reply
Posted by
uer166
on 24 May, 2022 06:46
-
It doesn't make much sense you're avoiding using a pre-made module, though. Many such modules are little more than the RF MCU and maybe an integrated antenna and some power supply support components like capacitors, ferrite beads, etc., and many of them are fully programmable just like the bare RF MCU chip. So other than costing $15 instead of $5 there's no disadvantage of using a module and the advantages are things like proven construction, more "ready to use" software tools etc.
What you say makes sense, but this is a learning exercise as much as a practical end result. Of course I would have
some amount of fail-safe: e.g. a nice and slow ramp to full regen braking, or some sort of warning so I could switch to foot-brake. I've been thrown off one of these before due to a BMS cell UV fault (full torque to 0 torque tends to throw you off balance), and it's not fun, so I would like to avoid it as much as possible, but it's not the end of the world if it dies and simply goes into a coast.
I would like it to be a really
nice single PCBA with everything: BMS, FOC motor controller, and radio. This is not how it's usually done, but again it's a fun project..
The avoidance of a module is 2-fold: I would like to try some minimal amount of RF PCB layout and RF validation, and I would like to be fully in control of the mechanicals of the system.
-
#8 Reply
Posted by
Siwastaja
on 24 May, 2022 06:57
-
IMHO, you have two realistic choices:
* Just add wires
* Go wireless and accept the fact you are taking a very real risk of the communication failing. Make sure your "fail safe" logic does not kill or injure yourself or someone else.
That being said, even if you add wires and have perfectly reliable communication (say, over current loop with optoisolation, or maybe RS422 or CAN), your motor control code can still misbehave, it's colossally difficult to write perfectly bug-free code.
So maybe if you go wireless, that existing risk just goes up by maybe two orders of magnitude. Maybe you can accept it?
But this is definitely something that calls for bare metal approach, i.e., no existing BLE stack.
One thing I would consider is adding dual radio, on different ISM bands, for example one at 2.45GHz band, one at 915 or 434MHz. More work, yes, and dual-MCU solutions suck development-wise, but that's the price you would pay for significantly increased radio reliability. And you still have zero guarantee.
Am I guessing correctly you would be just transferring some simple motor control parameters like speed or torque (< 10 bytes payload), at a rate such as 10-50Hz? Is it going to be unidirectional, or you need status information back from the motors?
-
#9 Reply
Posted by
uer166
on 24 May, 2022 07:03
-
Am I guessing correctly you would be just transferring some simple motor control parameters like speed or torque (< 10 bytes payload), at a rate such as 10-50Hz? Is it going to be unidirectional, or you need status information back from the motors?
1) Thanks for the great info/experience
2) Yup, uni-directional is fine. A few bytes at 10Hz say. Bi-directional is nice to have (BMS state, etc)
I've also considered using some sort of IR transceiver a la TV remote, or IR headphones, but I suspect the power requirements in the remote to overcome the sun radiation would be way too much for the required size.
-
#10 Reply
Posted by
Siwastaja
on 24 May, 2022 07:08
-
Well, the first prototype is very quick to do on nRF52. Just flood the packets on a single frequency, a few dozen lines of code. Enable RX, poll for EVENTS_DISABLED, check if you have EVENTS_END and CRCSTATUS is valid. Rinse and repeat.
Now with frequency hopping it gets a bit more difficult: you can't just keep listening anymore, you need to know when to listen, at what frequency.
It's still quite simple, you just decide that for example, you hop over 10 frequencies and listen for 20ms on each. If you get any packet through even once, you can synchronize the clocks, and being on the 32kHz watch crystal (for the Real-Time Counter peripheral on nRF52), the sync is good for minutes. Now you always know when to terminate RX, switch to the next frequency, and start RX again. Just a few dozen lines-of-code more.
Bidirectionality makes it again more complex, you have to divide time into RX/TX slots. Not too hard; make that 20ms slot 15ms listening and 5ms transmitting a reply, on the same frequency. Bidirectionality enables your master to know when the connection is lost, so maybe you can brake down other motors in sync, using similar ramp to the fail-safe code.
Your work is made somewhat easier by the fact you don't need to consider low-power operation (I'm assuming the "master" or controller side has decent battery as well. Motor side obviously does). So you can fill all unused time by just listening, and don't need a separate "sleep state" and special wakeup protocol.
-
#11 Reply
Posted by
uer166
on 24 May, 2022 07:18
-
That's more-or-less exactly what I had in mind. I just never realized how easy it seems to be to use the nRF hardware directly without all the BS. I've started reading through the STM32WL radio section in the reference manual and holy crap, I fully expected to dive into the weeds of modulation technique details and thousands of lines of setup and operational code. Seems like nRF hardware abstracts all that away and just works with whatever modulation/power/frequency settings you choose. I'm actually not convinced they don't have some embedded co-processor with ROM that essentially hides an otherwise large library.
You're correct in assuming that the remote battery is not a problem, 500mAh is easy, and can be recharged every ride anyway. And of course the receiving end has 0 concerns with RF power use considering ~2kW motors and a ~600Wh battery.
-
#12 Reply
Posted by
Siwastaja
on 24 May, 2022 07:21
-
Yeah, if you have at least some experience writing MCU register level code, you have custom NRF_RADIO application transmitting and receiving packets in a day, only referring to the "Product Specification" sheet and about 20 pages regarding RADIO (ignoring Bluetooth addressing and direction finding parts).
I recommend BLE LR 125kbps physical signalling for the best range (sensitivity). You get all the high-tech BLE radio signalling woodoo, without the higher level BLE protocol.
-
#13 Reply
Posted by
JPortici
on 24 May, 2022 07:24
-
I took chances with the nRF52 family, specifically Fanstel modules, but you can easily just use the nRF chip as is. Some key findings so far:
Hardware design and documentation is just excellent. This is the easiet-to-program (on register level!) MCU family I have ever used - including the RADIO peripheral!
As a massive contrast, the SDK / official software ecosystem is one of the most horrible, most complex jobs ever. Simplest of examples compile tens of thousands of LoC, and do not work out of box. You can't even get hello world, because hello world is printed using a custom NIH "logging library", which requires configuration (10kLoC configuration file) to work. I spent hours trying to fix the logging library and gave up.
...
This example shows how easy this is to use!
Neat! I was reluctant to try them because of the SDK. I had next to horrible experiences with SiLabs and their tools and was even more scared when i started looking at nrf52 for other stuff
-
#14 Reply
Posted by
jeremy
on 24 May, 2022 13:36
-
The nrf5 SDK is in maintenance only mode (ie they keep it alive for legacy customers, but otherwise you shouldn’t use it) and has been for some years now iirc. The Zephyr SDK is what Nordic expects you to use nowadays, and personally I think it is fantastic but the initial learning curve is very steep, particularly around the devicetree.
I have used nrf52 devices for BLE quite a bit, and the contrast between the nrf5 and Zephyr SDK is like night and day. I am not a fan of the nrf5 SDK.
Modules can be had for much cheaper from Chinese manufacturers “Ebyte” and “Minew” on Aliexpress (or direct from their websites). These are both official distributors for Nordic I believe. There is also this little guy:
https://www.seeedstudio.com/Seeed-XIAO-BLE-nRF52840-p-5201.html but it is so popular that it is permanently on backorder. I got mine after 4 months of being on the backorder list. Fanstel is good but their interesting modules all seem to be out of stock for the last year or so. There is also Raytac which I would say is the “go-to” module producer.
The main problem with using these devices without a module is that you need capped blind microvias to fan out the nrf52840 (it is a weird double row aQFN package), and that makes your prototypes very expensive.
-
#15 Reply
Posted by
jeremy
on 24 May, 2022 13:41
-
I'm actually not convinced they don't have some embedded co-processor with ROM that essentially hides an otherwise large library.
They definitely do not have a co-processor (except in the nrf5340 in which this is a feature) unless you consider a state machine a coprocessor. For BLE, it uses a “supervisor” model like the Dialog Semi parts. Basically, the “SoftDevice” (their radio firmware) is in control on the main CPU, and it passes you the execution as long as it isn’t busy itself.
-
#16 Reply
Posted by
Siwastaja
on 24 May, 2022 15:52
-
The nrf5 SDK is in maintenance only mode (ie they keep it alive for legacy customers, but otherwise you shouldn’t use it) and has been for some years now iirc.
Interesting to know. Just half a year ago, I spent some 30-40 working hours of work trying to learn and work with/around the nRF52 SDK, and nowhere I found this piece of information. Quite the opposite, the SDK was the only thing they referred anyone to.
But it became obvious it would be a few months of full time job to be able to actually develop anything with that complex pile of shit. The problem - once you invest many man-months in it (or man-years, if using less experienced developers), then you get to hear "oh btw, it's now deprecated, here's a new equally difficult pile of bullcrap with steep learning curve again and oh by the way,
this snake oil is the best thing since sliced bread".
The funny part:
* Peripherals are well designed and easy to use.
* The general idea of SoftDevices - using software interrupts to interface the library, removing compile and link time dependencies - even easier than classical "libraries", just flash the SoftDevice somewhere - is very good.
But all this is wasted by the fact that the process is undocumented and with zero examples. They only refer you to the SDK, and SDK examples. Which means, using it requires understanding which file of the 50 files and 100000LoC to start modifying. No "BLE hello world" anywhere. Instead of blinking an LED with one (1) line of code, they have a Button And LED Service, abbreviated BLS like it's some new fancy TLA, somewhere deep in the source tree.
I took the easy way out - just did not learn to use BLE. For me it was fine because I did not need interoperability with smartphones. The OP seems to have a very similar case.
-
#17 Reply
Posted by
Marco
on 24 May, 2022 23:20
-
I'd trust enhanced shockburst with your own frequency hopping over anything bluetooth.
-
#18 Reply
Posted by
uer166
on 25 May, 2022 06:08
-
The main problem with using these devices without a module is that you need capped blind microvias to fan out the nrf52840 (it is a weird double row aQFN package), and that makes your prototypes very expensive.
Luckily I'm looking at the smaller brothers such as nRF52811 in a nice and benign QFN48. I'd never use that weird 2-row package in such a high vibration environment anyway. Hope the QFN has wettable flanks so it can be checked.
-
#19 Reply
Posted by
JPortici
on 25 May, 2022 09:54
-
The main problem with using these devices without a module is that you need capped blind microvias to fan out the nrf52840 (it is a weird double row aQFN package), and that makes your prototypes very expensive.
Luckily I'm looking at the smaller brothers such as nRF52811 in a nice and benign QFN48. I'd never use that weird 2-row package in such a high vibration environment anyway. Hope the QFN has wettable flanks so it can be checked.
it looks like the very retarded VTLA that microchip used for some time (if i can name one good thing of chippageddon is that those parts were EOL'd and will never return to haunt us
)
-
#20 Reply
Posted by
uer166
on 25 May, 2022 22:49
-
Ordered some EV-BM833AF boards with a nRF52811, nice that the JTAG and USB and UARTs are all exposed. No idea what kind of libraries Fanstel provides, but hopefully can simply fire up Nordic's IDE and get in there right away.
-
#21 Reply
Posted by
Siwastaja
on 26 May, 2022 06:20
-
Ordered some EV-BM833AF boards with a nRF52811, nice that the JTAG and USB and UARTs are all exposed. No idea what kind of libraries Fanstel provides, but hopefully can simply fire up Nordic's IDE and get in there right away.
I started with EV-BC833 boards. I don't think Fanstell provides any useful code? Anyway, I spent a week trying to do something with the nRF SDK, got some Hello World compiled and running, failing to print Hello World. Also got Enhanced ShockBurst example successfully running, but that already required some modification. Then I modified the ESB code to switch it to BLE LR 125kbps mode.
What I finally did? Took my previous STM32 project, linker scripts and startup code and just modified with the correct memory addresses referencing to the nRF52 datasheet. Flash with
nrfjprog. First LED blinker running in an hour.
Freely configurable IO mapping is the best thing since sliced bread!
Fanstell Evaluation boards do not seem to match their datasheets, pin mapping is all different, go figure. This wastes some time. At least one of the LEDs was in the documented pin, another LED was not, and buttons were not.
A few months forward, I have my full custom radio protocol which works really well and I can also see the actual operating range is better than with the ESB, thanks to frequency hopping. It really makes a difference if you are behind some rebar concrete. My protocol is ACKless and based on periodic transmissions at known times, and retransmission requests being sent only when necessary. Every periodic transmission is followed by 1 to 4 rx-tx slot pairs, each at different frequency, so that missing periodic packets can be re-requested instantly, not messing up packet order. Only when there retransmissions fail too (resend requests getting queued in a FIFO), packet order starts to change, which can be seen from the sequence numbering.
-
#22 Reply
Posted by
uer166
on 29 May, 2022 04:06
-
Not gonna lie the first experience with the dev board is a little disappointing. They actually recommend buying the official nRF52DK dev board to use as a programmer for EV-BM833A, which is a little confusing. If I knew I had to do that I'd have bought the official dev board from the start anyway..
Regardless, I've been trying to use a ST-Link off of a Nucleo board to talk to the nRF52 chip on the Fanstel board without too much success. Something's happening but it seems to hang.. The MDK provided seems nice and minimal, and vanilla GCC compiles stuff fine, if only I could connect to the board. I'm also finding a lack of documentation regarding what official debuggers/tools are supported.
If anyone has any recommendation about how to program/connect/debug in command line ideally that would be great. I'm used to canned solutions from vendors (such as STM32Cube and Mplab-X, but Nordic does not provide such things, so it's a learning experience).
$ ../openocd/bin/openocd.exe -f ../openocd/scripts/interface/stlink-dap.cfg -f ../openocd/scripts/target/nrf52.cfg -c "gdb_flash_program $ ../openocd/bin/openocd.exe -f ../openocd/scripts/interface/stlink.cfg -f ../openocd/scripts/target/nrf52.cfg -c "gdb_flash_program enable" -c "gdb_breakpoint_override hard"
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-17:32)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.
force hard breakpoints
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V3J7M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.297211
Warn : target nrf52.cpu examination failed
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
shutdown command invoked
-
#23 Reply
Posted by
jeremy
on 29 May, 2022 05:48
-
-
#24 Reply
Posted by
Siwastaja
on 29 May, 2022 06:55
-
I just bought the recommended nRF52DK (and just use it as a Segger JLINK programmer) because this was paid work so wanted to minimize wasted time. Indeed, I'm using nrfjprog with it and... it just works. It's a bit confusing that if you miswire the JTAG, or just forget to power your actual target, then the nRF52DK silently targets the device on the nRF52DK itself, so you every now and then accidentally end up programming your binary on it... and even when it's a different MCU, it seems to be binary compatible enough that the RADIO does weird things! So then you want to erase it.
However, I did hand out prototypes of own BM833 (nRF52833) based design with just SWD connector exposed to someone who normally only deals with STM32 and said "try programming it". He succeeded with it, apparently, but I don't know what he exactly did.