Navigation

    • Register
    • Login
    • Search
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Koresh
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Koresh

    @Koresh

    Contest Winner

    161
    Reputation
    236
    Posts
    2781
    Profile views
    11
    Followers
    0
    Following
    Joined Last Online
    Location Minsk, Belarus Age 34

    Koresh Follow
    Hardware Contributor Contest Winner

    Best posts made by Koresh

    • MySensors 2.3 and RFM69 new driver. Problems and solutions

      Hi everyone. I want to share the results of a small investigation into MySensors 2.3 and rfm69 new driver environment. I decided to do it after I bumped into some problems.
      I hope it will be interesting for everyone. Newbies can find simple recommendations to improve MySensors stability. Experienced users end core team members can implement my ideas into the mainline version in the right way.
      Let me remind you of the problem briefly. If you try to run this code to send two messages from the node to gateway only the first message will be sent properly.

      send(message1, true);
      send(message2, true);
      

      Chapter 1. Second ACK
      Let’s see how mysensors with rfm69 processes incoming messages. Just when rfm69 receives the message, it generates interrupt which is handled by rfm69 driver. But… in this interrupt the driver does not process the message. It only sets RFM69_irq flag.

      // IRQ handler: PayloadReady (RX) & PacketSent (TX) mapped to DI0
      LOCAL void RFM69_interruptHandler(void)
      {
      	// set flag
      	RFM69_irq = true;
      }
      

      Later process() function reads this flag and reads messages from rfm69. So the first important point. Incoming messages can be processed only in two places of application code:

      1. Inside the process() function at the beginning of the main mysensors application loop.
      2. Inside the wait() function anywhere you call it (it actually calls the process() function too).

      0_1531061212559_MysLoopDiagram.png
      There is only one exception to this rule. Just when you send any message with ACK request, the rfm69 driver is waiting for the ACK message. So at this moment your application can get a message too. If it is an expected ack it will be processed, otherwise – just received and not processed.

      Now we know a little more about how mysensors processes incoming messages and I will try to describe how a very simple usecase works. Let’s imagine that the node sends one message to the gateway

      send(message1, true);
      

      In the following diagram I tried to explain in detail the behavior of the application from both sides – gateway and the node.

      0_1531061319581_OneMessageDiagram.png

      As you can see this case works properly.
      Now we can imagine a more complex case. The node sends two messages to the gateway one by one.

      send(message1, true);
      send(message2, true);
      

      Yes this is the same code which I wrote at the start of this topic. So the next diagram describes how it works.

      0_1531061380920_TwoMessagesDiagram.png

      Oops… The second ACK will break the communication in this case? Yes – 99% it causes the problems. But why is this second ACK needed at all? I am not entirely sure, but I will try to explain my understanding of this second ack (how it should work).

      0_1531061521771_SoftwareAck.png

      So this second ACK theoretically can help you know if your message was delivered to the node which is behind the gate. But in real life it brakes the communication.

      How can we fix it? How can we send two messages one by one without collision? I will describe some solutions.
      First solution is very simple but very bad and I strongly recommend against implementing it. Just add wait(100) between the lines

      send(message1, true);
      wait(100);
      send(message2, true);
      

      Why is this solution bad? First it causes a dramatic rise in battery consumption. There are two messages in this case. If you want to send 4-5 messages our sketch will work 400ms longer! Second it is absolutely wrong from the application design point. We are trying to fix the transport layer error on the user application layer. So implement this solution as last resort.

      Second solution is not a very good one but I would recommend it for anyone who uses simple mysensors setups with relatively simple sketches without any complicated customization. Just disable the second ACK!

      //MyTransport.cpp line723
      // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
      #ifndef MY_RADIO_RFM69
        (void)transportSendRoute(_msgTmp);
      #endif
      

      or just comment it 🙂

      // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
      //(void)transportSendRoute(_msgTmp);
      

      This simple hack will increase your network speed and reliability sharply. For example this code

      for (int m = 1; m < 200; m ++){
           send(msg_sw.set(m), true);
        }
      

      will send 200 messages with ACK requests one by one and not a single NACK has ever appeared. I tried it many times.
      What do you lose if you implement this solution? You will not see this message

      45899 TSF:MSG:READ,0-0-144,s=1,c=1,t=2,pt=1,l=1,sg=0:0
      45905 TSF:MSG:ACK
      

      in the debug serial output of the node. I think 95% of users do not process such messages in the sketch and it is not a big loss.
      If you want to process these ACK messages to check the delivery to the node which is behind the gate you can implement the third more clever solution

      // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
      #ifndef MY_RADIO_RFM69
      #ifndef MY_GATEWAY_FEATURE
        (void)transportSendRoute(_msgTmp);
      #endif
      #endif
      

      Or

      // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
      #ifndef MY_RADIO_RFM69
      if (_msg.last != _msg.sender){
        (void)transportSendRoute(_msgTmp);
      }
      #endif
      

      It makes your network more stable too. In the first example we disable software ACK (second ACK) from the gateway to the node. In the second example we disable software ACK from one node to another node if there are no nodes between them (I haven’t tested this case but It can work).

      But imagine you do not want to implement this hack at all. How can we fix this problem differently? Let’s move to the next chapter.

      Chapter 2. The queue of the messages.
      The messages queue is standard in different systems. It is nonsense to omit this feature in a serious system. Moreover, MySensors team implements this feature… but for NRF24 not for RFM69.
      I will not describe in detail how message queue works. You only should know that received messages are read immediately after they are received (inside the interrupt handler) and put into the queue. They can be processed later but we do not omit a single one.
      I will try to implement queue message for the RFM69 transport and drivers level. I have a very good example for NRF24 so it was not very hard. I bumped only into one serious problem (yet:)). NRF24 driver uses autoACK function, which is not supported by rfm69. If we want to send ACK inside the interrupt handler we can’t use time system functions (millis(), delay() and so on). So I implement Ack sending function without forbidden functions.
      You can see my draft solution on the easysensors github (will share soon, may be today). Most of the changes are in the MyTransportRF24.cpp and RFM69_new.cpp. If you want to try it you should also remove mysensors capabilities protection like this in some places

      #if defined(MY_RADIO_RFM69)
      #error Receive message buffering not supported for RFM69!
      #endif
      

      I haven’t tested it thoroughly. But I have tested it to check if «DOUBLE ACK» problem is solved. And yes – it is solved. The next diagram shows how this code works with my new transport and driver

      0_1531062561670_TwoMessagesDiagram_queue.png

      I hope core team members will help me integrate this driver into the mainline code.

      Chapter 3. General recommendations and simple driver fixes.
      You can easily increase communication speed for the new driver. Just change on line in RFM69_new.h

      #define MY_RFM69_CSMA_LIMIT_DBM             (-95)			
      

      -95dbm is a VERY optimistic expected noise level for such popular frequency bands and amateur power supplies. I suggest use -90 or -85.

      It is foolish to send a message if the air is busy. But the new driver (and an old one, too as far as I remember) tries to send a message even if the air is busy (checks the air, waits for 500m… and sends 🙂 ). We should add some lines:

      //RFM69_new.cpp line 382 (before // set radio to standby to load fifo)
      if (!((hwMillis() - CSMA_START_MS) < MY_RFM69_CSMA_TIMEOUT_MS)){
        return false;
      }
      

      And of course it’s irrational to wait for an ACK if the message wasn’t sent. So we need replace one line to prevent it.

      //RFM69_new.cpp line 620 (before // radio is in RX)
      if (!RFM69_send(recipient, (uint8_t *)buffer, bufferSize, flags, !retry)){
      	continue;
      }
      

      Many thanks for reading this article till the end.

      posted in Development
      Koresh
      Koresh
    • RE: 💬 Wall Switch Insertable Node

      Oh.. Earlier I received cr2032 holders instead of cr2450. And now I've received cr2477 instead of cr2450... It's better, because it's possible to cut holders so they can be compatible with cr2450 battery 😛
      alt text

      And I'm ready to start mass testing 😃
      alt text

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: Very strange bugs. 2.3. RFM69.

      Yury and I have been digging deep into the new RFM69 driver and MySensors 2.3 for the past two days. I think it needs a lot of work so far. But good results have already been achieved 😄
      Now I can send lots of messages which requested ACK one by one without any wait between them (we tested 200 messages) and not a single NACK has ever appeared.
      Will share results soon.

      posted in Troubleshooting
      Koresh
      Koresh
    • RE: 💬 Just RFM gateway

      0_1489144301061_IMG_2017-03-10_133853.jpg
      It works! 😄
      Have uploaded some photos. Will share project sources soon 😉

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 Button size radionode

      So I am ready to present estimated prices to all my new boards.
      The estimate is too rough because I am not sure about size of the production batch. But it's better than nothing. Prices include pcb's, components and assembly. Configurations are not fully accepted yet.

      ---WALL SOCKET INSERTABLE NODE
      BASIC (ac/dc, atmega, rfm69, 10a relay) - 9.5$
      ADVANCED (ac/dc, atmega, rfm69, 10a relay, current sensor, rgb led) - 10.8$
      MAX (ac/dc, atmega, rfm69, 10a relay, currrent sensor, atsha204, watchdog, rgb led) - 12.2$

      ---WALL SWITCH INSERTABLE NODE
      BASIC (atmega, rfm69, buttons controller, JST wires) - 6.5$
      MAX (atmega, rfm69, buttons controller, JST wires, atsha204) - 7.5$

      --BUTTON SIZE RADIO NODE
      BASIC (atmega, rfm69) - 6$
      MAX (atmega, rfm69, atsha204) - 7$

      --SECRET TTL-USB
      BASIC - 1.4$

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 Wall Switch Insertable Node

      I've added SPI flash for OTA on this board too. And I've replaced 0402 components to 0603 so this board becomes not so crazy 😀
      alt text

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 MySensors Contest 2017

      alt text

      posted in Announcements
      Koresh
      Koresh
    • RE: 💬 MySensors Stable Node

      First small batch is completed 🙂
      0_1458050420487_DSC02594.JPG

      0_1458050451893_DSC02595.JPG

      0_1458050456651_DSC02596.JPG

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 Baby BusyCube design journal

      0_1501169507551_image-0-02-04-ddd00b913561a0c9d3a314a42c03d4c754930ff4880935f4ea3a247666839ded-V.jpg

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: Your workshop :)

      0_1459889199847_PANO_2016-02-17_153754.jpg
      😏

      posted in General Discussion
      Koresh
      Koresh

    Latest posts made by Koresh

    • RE: 💬 Button size radionode with sensors swarm extension

      Hope will test the new version of this universal board soon. Now it has additional inexpensive accelerometer, magnetic sensor, led, reset button, multifootprint for lora/hw/cw radio without adapter and improoved 4layers design 🙂
      0_1563489045797_IMG_20190709_173131.jpg

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: Pir AS 312 with 2 rechargeable AAA battery. Boost needed?

      Hi. I use TPS61221DCKR for boards with such PIRs.

      posted in Hardware
      Koresh
      Koresh
    • RE: 💬 Button size radionode with sensors swarm extension

      @christoph-blank Hi, thanks for using this board. In the first version of this board the divider is conected after LDO, so you can't measure voltage above 3.3V. In the second version the divider is connected to the battery directly. You use 3.2v battery so it is not problem for you. But LiFePo4 battery has very flat discharge curve so it can be hard to read this level with reasonable accuracy.
      alt text
      I will try to find LiFePo4 battery and add some piece of code soon. Yet you can play with followed code

        // Get the battery Voltage
        int sensorValue = analogRead(BATTERY_SENSE_PIN);
        // 1M, 470K divider across battery and using internal ADC ref of 1.1V1
        // ((1e6+470e3)/470e3)*1.1 = Vmax = 3.44 Volts
        /* The MySensors Lib uses internal ADC ref of 1.1V which means analogRead of the pin connected to 470kOhms Battery Devider reaches  
         * 1023 when voltage on the divider is around 3.44 Volts. 2.5 volts is equal to 750. 2 volts is equal to 600. 
         * RFM 69 CW works stable up to 2 volts. Assume 2.5 V is 0% and 1023 is 100% battery charge    
         * RFM 69 HCW works stable up to 2.5 volts (sometimes it can work up to 2.0V). Assume 2.5 V is 0% and 1023 is 100% battery charge  
         * 3.3V ~ 1023
         * 3.0V ~ 900
         * 2.5V ~ 750 
         * 2.0V ~ 600
         */
      
      #ifdef  MY_IS_RFM69HW
        int batteryPcnt = (sensorValue - 750)  / 1.5;
      #else
        int batteryPcnt = (sensorValue - 600)  / 3;
      #endif
      
      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 Button size radionode with sensors swarm extension

      Hi @bjornhallberg.
      I've done many tests today with your code. All tested boards were the newer ones. So I completely had no ideas until I read your last message. Now all is clear for me. You have battery draining ~10-100ua, not 1-2mA. As I see your boards contain 107J capacitors. It was an absolutely failed batch of capacitors. We resoldered all of these capacitors on all the boards after we had found this problem with @alexsh1. Unfortunatelly some of these boards had been sent until we found this problem. We are so sorry you had to deal with these failed boards. I suggest I send you some new tested buttonsized v1 boards to you. Also I can send good capacitors to rework failed boards and some of my new interesting boards for free.

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 Button size radionode with sensors swarm extension

      @diogoc I will try to find them. But all of components are 0402... 👀

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: 💬 Button size radionode with sensors swarm extension

      @gerator Oh.. so sorry. It is new forum reporting system. Didn't saw your message.
      A6 reads unregulated voltage (3.5-6.5V) through divider (1/3). So it can't destroyed nothing.

      posted in OpenHardware.io
      Koresh
      Koresh
    • RE: MySensors 2.3 and RFM69 new driver. Problems and solutions

      @jkandasa said in MySensors 2.3 and RFM69 new driver. Problems and solutions:

      @mfalkvidd @Yveaux Do we have any plan to implement this changes into MySensors mainline?

      We can intensively test this branch if it will appear.

      posted in Development
      Koresh
      Koresh
    • RE: AC-DC at own

      @axillent I can't see the gerbers or sources of the latest board (din shape). I've seen your transformers on ali. It is perfect. I need auxiliary coil for my projects so I should place custom order on the factory.

      posted in Hardware
      Koresh
      Koresh
    • RE: AC-DC at own

      @axillent No, I just want to look at it.

      posted in Hardware
      Koresh
      Koresh
    • RE: AC-DC at own

      @axillent greate work ! It is very hard to order transformers... My congratulations! Can you share the pcb for the review 🙂 ?

      posted in Hardware
      Koresh
      Koresh