Project Logs

Collapse

• Source of components

  trax • 06/30/2022 at 10:30 • 0 comments

  Just a little note on where I sourced some of the components:

  Yes, it is the cheap-o USB travel charger.

  This little thing had many good parts required for this project:
  

  • Step up converter
  • Li+ charger IC
  • MOSFETs
  • Li+ Battery

  It also has a battery protection IC but I decided not to use it in this project.

  The step-up converter used in travel charger is responsible of providing 5V out of Li+ battery which can be anywhere from 3.7V to 4.2V.

  However, in my project, I actually step up the solar panel voltage to 5V and power the Li+ charger IC from it, which in turn charges the battery. Then the battery is being used through a MAX8888 LDO to power the ATmega328P and nRF24L01+ module.

  The 1W LEDs are directly connected to the battery and switched on via N channel MOSFETs.
  

• Range issues and fixups

  trax • 06/30/2022 at 10:21 • 0 comments

  Yesterday I tested the range of nRF24L01+ modules used in the device and I was not happy. It was simply not working as reliable as it must so I made a little change.
  

  I had to switch to the version with PA+LNA (which I luckily had at hand). These work much better and hopefuly it will not drain the battery too much during RX/TX.

  It had to be connected with wires because this version is much "longer" and there is simply no space in the current enclosure.

  It works!
  

• LEDs mounted and casing change

  trax • 06/29/2022 at 13:14 • 0 comments

  LEDs have been mounted and covered with epoxine.

  Solar panel will be mounted on the other side, and the "slot" will be covered with a plastic cover. This is just to protect everything from the rain, since it is better to have the big opening facing down.

  A very small hole will be drilled for wires coming out of solar panel (under it) and everything will be siliconed.

• Looking alive (debugging)

  trax • 06/27/2022 at 11:21 • 0 comments

• More motivation

  trax • 06/27/2022 at 10:43 • 0 comments

  The summer is once again almost here. Roads are dry and straight. Crap.
  

  Last night it was impossible to fall a sleep until 00:30 because some idiot was riding a racing motorcycle at 200km/h in front of my building. Mind you, it is a great opportunity to do it because the road is straight and nobody is around. However, the mega loud noise it produces is the issue I am trying to resolve with this project.
  

  I have given up on calling the police, because it does not make sense to call them every week. They simply don't give a crap... maybe I should join the police or buy a motorcycle? Both of these would solve my problem.

  In the meantime, looking like a zombie is my new image.

• The Controller (aka Remote)

  trax • 06/27/2022 at 10:26 • 0 comments

  I mentioned elsewhere that I will be using the Raspberry Pi in order to remotely control the device. I have a "pi hat" I designed for my previous project (it has a MAX485, a cooling fan and nRF24L01 receptable/pinheader). Of all this I will be using only the nRF24L01. I may even put the one with Power Amplifier on the Raspberry Pi.

  Software for the Raspberry is written in Python and it currently contains only the test code. You can check it out in the Github repository.

  I am using LeeKoq library (for the KeeLoq) and NRF24 library for the nRF24L01. The main entry point is the rftest.py script.

  When started, it loads the tx_counter.txt file which is used to keep track with the receiver (actually it is the other way around) and is incremented after each successful transmission. nRF24L01 has a confirmation for packet reception so I use that feature in order to not increase the synchronization counter more than required.
  

  Note: The current rftest.py does not verify the authenticity of received transmissions from the device. This will be implemented in the real program/script.
  

• Battery consumption optimization

  trax • 06/27/2022 at 08:45 • 0 comments

  Even though I implemented everything in such a way so that ATmega328P is sleeping whenever it is not doing anything special, I forgot to put nRF24L01 to sleep as well. This resulted in constant current consumption of ~17mA which drained the battery from 4.2V to 4.0V over night.

  The original idea was to wake-up the ATmega328P whenever nRF24L01 receives a valid packet via it's IRQ pin but this needed more work.

  Now I implemented a mechanism where the device is in sleep mode, including the nRF24L01 for a predefined time-slot (4 seconds) after which the nRF24L01 is set to RX mode (listening for RF packet) for 1 second. In case it doesn't receive anything within that 1 second it goes back to sleep for next 4 seconds and so on. During that 1 second listening time, ATmega328P is actually sleeping - it will be woken up by the IRQ in case something is received.
  

  This all means that the device is unavailable for 4 seconds maximum, which is just fine.

  After the device is "woken up" it will remain in constant listening mode for 2 minutes. On every received valid command this time is reloaded for next 2 minutes. In case nothing is received it will go back to usual sleep mode (4 seconds sleep / 1 second listen).
  

• Last minute hardware changes

  trax • 06/27/2022 at 08:38 • 0 comments

  LDO change
  

  Since this thing is powered by a Li+ battery (4.2V max) I needed to drop it to 3.3V for nRF24L01. This means using either some sort of buck converted or an LDO. Buck converter would be an overkill since voltage difference is not that great, neither are the currents, so I opted for the LDO AMS1117-3.3V. This was actually a bad idea since the voltage drop is too big, and I couldn't get more than 3.1V at the output. This meant some last-minute changes and LDO replacement, so I went for the MAX8888 LDO which is excellent for this application.

  Now I have a good 3.3V for entire usable range of battery voltage.

  Crystal change

  The idea was to use the external clock for ATmega328P but later on I found that I should better use the crystal clock inputs to Asynchroniously clock the internal Timer and implement an RTC. I removed the 8MHz crystal and soldered on the 32.768 kHz one and configured ATmega to use internal 8MHz clock. Now I have a somewhat accurate RTC (but not really because of the temperature drift). The RTC can be set remotely via the controller. Now I only need to figure out what to use it for instead of simply counting seconds and minutes for periodic operations (e.g. telemetry event).
  

• Telemetry data

  trax • 06/27/2022 at 08:26 • 0 comments

  Since the device will be deployed outside, battery powered and re-charged via solar panel I thought it would be a nice idea to have it send me some periodic (or upon request) telemetry data. This includes:

  • Voltage of the solar panel
  • Voltage of the step-up converter afer the solar panel
  • Current battery voltage
  • Battery charge indicator (charging/not-charging)
  • Ambient temperature
  • Battery charge time (since last report)
  • Number of received RF commands but with a failed MAC (KeeLoq hacking attempt)

  The telemetry data sent by the device to the controller is also protected with a MAC so that I can verify it is the device sending me this data, not someone else.

• KeeLoq on 2.4 GHz

  trax • 06/27/2022 at 08:16 • 0 comments

  After the device is deployed on the field, I need to make sure it is not misused by others eavesdropping on nRF24L01 packets. I wouldn't want someone else triggering the LEDs thus revealing the location of the device more than necessary.
  

  I could have used AES encryption to build a MAC (message authentication code) to verify authenticity of the transmission and also use a synchronization counter for re-transmission protection, but since this whole project is about re-using old parts I thought why not use old code as well.

  In one of my previous projects I worked with KeeLoq so I decided to re-use it to ensure some sort of protection against device takeovers. KeeLoq algorithm is known and is more-less crackable, however with secret 8 bytes-long encryption key it is still not feasible that someone will attempt to attack this little device. For those who succeed - they can take it away as a gift.

  The secrecy of transmission is not important in this device so KeeLoq is used only to prevent replay attack and for the authentication of the controller (me).

  Data which is prepared/encrypted with KeeLoq is transferred over nRF24L01 and it's 32-bytes long packets. KeeLoq ciphertext is only 4 bytes long and is used as a MAC (as a rolling code), while remaining of the payload is some other "application specific data".

  The "application data" transferred between the controller and the device also supports key-change, meaning I can change the KeeLoq "crypt key" any time I like after the device is deployed.
  

View all 11 project logs