I searched for other solutions to implement a low voltage discharge protection for single LiFePO4 cells and came across this solution(which combines it with reverse battery polarity protection).
With following diagram:
Note: M3 is a P-channel MOSFET but (incorrectly) drawn as N-channel.
The reverse battery protection (top right MOSFET) uses almost no current, but the low voltage discharge protection constantly draws up to 20 uA (R2,R3). The battery protection boards mentioned earlier use much less: max 5 uA (if their advertised specs are correct).
This is my Cargobikometer demo solution for the ADFC Berlin fLotte project, which is currently under development. The hub dynamo can be driven by hand or by a DC motor. The signal from the hub dynamo will be converted from a sine wave into a rectangle signal by a schmitt trigger. To avoid an always running hub dynamo during programming, I use a simple ESP32 based signal generator with touch sensors for switching the frequency. For fun I drive a little motor from the hub dynamo voltage with an AC-DC converter.
The program for counting the distance works very well, but now I have to transmit the distance value via LoRaWAN. The program for sending a fixed distance value via TTN http integration works also very well, but if I put both parts together, the pulseIn function returns always zero.
I already posted the code examples 2 days ago in the forum.
It would be nice, if somebody can help me to fix the problem. When the problem is fixed, I can move to the next step in my project, finding a suitable battery backed hardware device and a waterproof case, which should be placed on the bottom side of the cargobike.
I think that the dynamo measurement can’t be interupted for LMIC So my first idea would be to
use A - a non LMIC node or B - an interface between the dynamo and the node, maybe small pre processor ATtiny 85 / I2c
Your frequency measurement stuff looks quite complicated. Instead of blocking to measure on and off time, you actually only need to count cycles by detecting the rising edge.
I would setup an edge triggered interrupt to increment a counter. Read that value every second and you have your frequency.
You can definitely do this and run LMIC on the same chip.
OK I’ve printed it and its clear that you later decided to ‘hack’ LoRaWAN to the original code and that gives (timing) some problems.
Have a look into this (later), I understand what @cjhdev mentioned, but that requires a complete rewrite of all the code.
I read comments in the web some months ago, that frequency measurement works better for low frequency signals (1 to 100 Hz) by measure the period of the signal. Therefore I switched from interrupt based measurement to the current mechanism.
The part I dislike most about making prototype PCBs from scratch is flashing the bootloader. So I made this device to make that task simple and stress-free.
I have a few LoPy and FiPy boards and the Pycom ABP example has always worked out of the box.
Are you having an inssue connecting a programmed device to TTN or defining the application/device as ABP on your TTN control panel?
Hi @Lichtschilder, the project that I’m working on has done a lot of “walk-testing” but we have not used TTNmapper as we need to keep our own records and integrate with our RF coverage planning tools and Google Earth.
We use Lopy4 + Pytrack units and walk routes sending an uplink every 2 mins and locally record the uplink no., GPS co-ordinates, etc. on the Lopy4 storage. Then we merge with a record of the uplinks received on TTN and produce standard GPX files that can be viewed on Google Earth along with the predicted RF coverage in KMZ files.
An example walk through a predicted coverage gap in between three gateways about 10km apart in hilly country is shown below. The green waypoints show successful uplinks. The numbers are the uplink number and the count of gateways that received the uplink.
Development of this system on Lopy4 took about 3 days.
Hi Tim, am curious do you send at a single SF (which one) at any given location to determine coverage or do you tx at multiple SF’s to determine a ‘heat map’?
A skeleton GPX file of waypoints is kept during the walk.
An MQTT subscriber is recording all the uplinks that are received by TTN.
After the walk the skeleton GPX file is downloaded from the Lopy4 and is manually edited using the recorded MQTT/JSON data and comments added, etc.
Then it’s just Google Earth and import the RF coverage KMZ files and the GPX waypoints.
My plan has been to develop this forwards to run each waypoint at SF of 7, 10 and 12.
I would also like to run the RF coverage prediction models for SF 7, 10 and 12.
Then compare it all.
Sadly, the steamroller of work means that currently it’s running only at a hard-coded SF12 and the RF coverage predictions are also run for my best estimate of setup for SF12.
One of the key purposes for us was to test-drive various RF coverage prediction models for large-scale use in rural areas, specifically post-glacial Scotland. Result… most are pessimistic for LoRaWAN but give a reasonable representation of “guaranteed coverage”.
Project decided that info was good enough, move on.