What is Home Smart Mesh ?

As described in the Home Smart Mesh Hackaday Project, it is an IoT Mesh Framework using custom RF sensors and repeaters for Raspberry Pi. It is Open Source, and plugs with MQTT and OpenHAB2.

The mesh protocol has been designed to be simple enough so that you can understand it and debugg it by yourself in your free time, yet with a functionnal level that can be of a practical use. More details about the mesh protocol in this flood mesh project log

STM32 Hardware Support

• RF Node : already running with source code available on github STM32 RF Node Projects
• RF PIO : same in github firmware for pio servo control

STM32 Applications

• heater : a pwm control of a Solid State Relay
• sniffer : not really RF sniffer, but protocol sniffer, as it ignores the format but still has to stick to one channel, helps to see both request and acknowledge for debug.
• uart interface : 
  • RF dongle collecting messages broadcasted into the mesh
  • Injects messages targeted to a specific node with an acknowledge. Note that the acknowledge is mesh wide from destination back to source and not point to point like the Enhenced Shockburst.

Now as we can see in the following sections the STM32 bring the possibility to use ARM mbed and all what comes with it.

Easy to use Mesh functions with ARM mbed and modern c++

Here we can find code snippets from the RF uart interface acting as an RF dongle. Complete file on github

//nRF Modules 1:Gnd, 2:3.3v, 3:ce,  4:csn, 5:sck, 6:mosi, 7:miso, 8:irq 
RfMesh hsm(&rasp,           PC_15, PA_4, PA_5,   PA_7,  PA_6,    PA_0);
void rf_broadcast_catched(uint8_t *data,uint8_t size)
{
    switch(data[rfi_pid])
    {
        case rf_pid_0xF5_alive:
...
int main()
{
   hsm.init(CHANNEL);
   hsm.setNodeId(NODEID);
   hsm.attach(&rf_broadcast_catched,RfMesh::CallbackType::Broadcast);
... 

• Provide the Channel to listen and send on. Can be changed later. And yes, currently the mesh is operating on a single channel, channels clusters and channels swapping are features yet to come depending on need.
• Attach to a mesh event, here a broadcast

Here we have a code snippet from a Node application that uses acknowledged peer to peer messages. complete file on github 

void rf_message_to_me(uint8_t *data,uint8_t size)
{
    if(data[rfi_pid] == rf_pid_heat)
    {
        heat_val = data[4];//heat_val payload : Size Pid  SrcId TrgId  HeatVal CRC
...
main()
{
   hsm.init(CHANNEL);
   hsm.setNodeId(NODEID);
   hsm.attach(&rf_message_to_me,RfMesh::CallbackType::Message);
...

•  The attachment is to a Message type.
• As the node id has been provided to the mesh driver, only messages with matching target node id will be provided.
• The acknowledge transmission is also handled by the mesh driver.

Debug like a professional

• I regret all the time I lost being prevented from real debugging to the excuse of low cost flasher and using the ST-Link and co.
• I had to move to the nRF family for single SoC with ARM-M0 and RF, so I had to have a flasher and debugger
• Note that updating an ST-Link to J-Link OB and using it with other than ST components is illeagal.
• So I decided to get a j-Link EDU

Why a j-Link EDU ?

• No need to argue too much for reasons such as "It simply works!", it is true, I tried it, also compatibility with all serious and open IDE, so let us focus more on comparison
• Compared to an ST-Link, you get with the j-Link a VTref input that sense your target voltage so that you can automate scripts using that.
• Note that the EDU is relatively cheap (60 €) usage for hobbyistes and education only, but there is an even cheaper EDU-mini (16 €) but for cortex M only.
• The EDU over the mini has a higher download speed, and more CPU variants support.
• It can control the power up to 300 mA 5V to switch your target completely off, which is important in tests automation as it is not the same as a reset.
• It has a virtual UART, not the hoisting used from the ARM cortext, but you keep your ARM program unmodified using the external UART and connect it to the external pins of the debugger.
• So you have all in one : Debugger, Power control, Voltage sensing and UART
• The segger devices security is improving, so spare yourself the pain of clones that would stop working after SW updates. 

Where to go on from here

• I will start updating my scripts and environment to use the j-Link edu, I will break the compatibility with the ST-Link utilities.
• I'll evaluate debuggers interfaces Ecpilse and segger specific
• I'll start using python to wrap the debug interface and make it quick and accessible

Experimentation setup

• The PS4 Joystick is a good way to manipulate multiple variables simultaneously which is suitable for experimentation. The touch pad adds possibilities for position reference.
• The Raspberry pi here is not needed for the BLDC control but is acting as the Joystick interface plus its development environment is more suitable for programming.
• Although the RF Node Board has a USB built in, the USB SW is complicated to integrate and uses memory, so the UART has still time to live in experimentation. A USB to UART brings it down to the same.
• The RFPIO Board was intended for servomotors control not BLDC, but is a good platform for BLDC experimentation as it exposes the PWM outputs and has radio connection.
• The Radio connection is not of much use here, but it is actually practical and very important isolation medium between the Test PC and the motor test bench. That advantage is not used here but only because the power supply has regulated current.

• A cheap logic analyzer is being used in the button mode that works with the Saleae Logic SW which is a great and affordable combination for analysis.
• A commercially ready module is used for the L6234D from eBay, but this one does not offer much options as all enables are joined together and there are no sensing resistances. So this can only control in Open Voltage Loop.

Demo

The interesting part in this demo is not the revolution of turning a bldc for the first time, rather :

• The integration of such a number of small peaces of SW on different environments
• The approach how someone could have a feeling of how a BLDC motor works by directly manipulating multiple variable and seeing the pulses on a logic analyzer

Open Loop Control : BLDC = Stepper motor

• It is always possible to change the voltage in every coil without regarding the position of the rotor.
• That definitely would result in missing steps if the voltage is not enough to deal with the torque. As in BLDC steps are big, missing them do hurt and does not go unnoticed.
• The solution is to increase the voltage, but then you're wasting energy that does not go in torque but in flow to maintain the motor position. The current is much higher when the motor is at rest due the absence of counter electro-force.
• The used BLDC motor here consumes around 50 mA at a speed of few rotations per second and up to 180 mA at a stopped position with 7.2 volts.

Control Parameters

Every new video or diagram about BLDC control allows me to understand something more, that's why, in spite of the number of documents and tutorials in the internet, why not add another simple view on this.

• The speed acts on the delay before applying the next electric angle position, note that the maximum command update frequency is less then the pwm signal frequency otherwise it is useless (figure not of same scale for both).
• The voltage is increasing the pulse width. Although only one pwm signal is displayed here, all of the 3 signals proportionally increase and decrease their width pulses.
• The position is even simpler from software point of view as you just have to increase or decrease the electrical angle proportionally to the movement of the finger on the touch pad. The sinus of every angle is taken to define the pulse width of the corresponding bridge.

Software

Sorry for placing source code as pictures but the source code plugin is so lame that the code is barely readable, so I keep the VSCode colors.

All the bldc magic is here. The angle is taken as an int to make it simpler, I'm not even using a proper unit as radions or degrees rather a 256/360° units so that it fits a 256 table where the sinus is porecessed once and stored as lookup.

• The live calculation of floats with this M3 running at 72MHz took 7.2 us while the lookup function here just around 1 us so it is still worth it for a 50 us pwm period = 20 KHz (maximal control refresh rate).
• Note that the L6234D can go up to 150 KHz from the dead switching time point of view.
• I am using the mbed-os as development environment so why not simply use ?

PwmOut pwm1;

pwm1 = 1;

That's why you see the direct usage of the registers which is around one instruction.

Signals

• We can see the center aligned pwm signals on the logic analyzer.
• Note that the frequency is displayed as 10 KHz not 20 KHz mentionned above, which is correct as sticking two pulses together reduces the variations to half.

Conclusion

Once you control the speed and voltage simultaneously, you get a better feeling on when the motor stalls and misses steps, you can hold it and apply a higher voltage to see when it overcomes the torque applied. That is not science, but that is the experience that makes you comfortable to deal with the rest of the scientific formulas.

Next steps would be to look on a torque control loop, then maybe Back-EMF monitoring, designing a specific extension board for BLDC and meditate in front of Field Oriented Control videos. But what is sure is that for my plans of inverted pendulum mobile robot, this control is already enough.

The RF Node with sensors is up and running, the RFPIO is up and running, time to think on what should come next.

• Ultrasound cartography using multiple low cost HC-SR04 or 05
  • see Hello_Ultrasound sample for experiments.
  • The extension board should provide ready to connect pinout for multiple ultrasound sensors
• BLDC : After very long hesitation and reflextion time, a serious jump into robotics playground cannot go around motors control
  • Using L6234 PowerSo20 modules or maybe later some lower current L6234 DIP directly on the same board.
• Servos only : The RFPIO double usage of x24 pins and x12 servos is not of optimal size for servos only usage, maybe another optimal layouting could be more convenient for some crazy many servos projects.