Trap notification project – advice re devices please.

@john-nz As long as you have reasonable line of sight between the Lora sender and receiver that will work fine. I would build a simple sender and receiver first to test if the signal can get through. The only thing to be aware of that I did not see in your specs is a way to check validity of message, some kind of ACK/NAK and retransmission etc. Not that hard, but it needs to be bullet proof. Lora is a simple protocol with no in-built message delivery guarantee.

Thanks Ron. How would it be if I set the message length as a variable in the sender, and transmitted that with the message. Check that the received message length matches the variable - if so, send confirmation back. Sender checks for receipt of acknowledgement, resends if no acknowledgement received within given period (10 seconds?). Count resends and stop if, say no acknowledgement after 10 resends. 

@john-nz 10 secs is like a year in computer time, maybe 1 sec. EVERY message has to have checking. I have experience in this area when I was reading all the market data globally and consolidating it into a world feed. Of course I was using a line protocol with checking, LORA does not have any. 

I can't lay my hands on my notes at the moment, but I think my LORA protocol was about 10 bytes or was it nybbles  per message of overhead. As a minimum,  1 byte length then inverted(1's complement), a byte of 1's and a byte of 0's. Since you are only using a couple of very small message types you probably do not have to worry about structure alignment. Every new hire we had would trip on that. 

Remember, probably every other transmission protocol you have used had additional layers that did this for you, with LORA you are responsible for EVERYTHING going out the antenna but more importantly, coming in and that includes every electric motor, automobile, machinery etc. There will be lots of random noise so to distinguish your messages from random you need to include very specific non-random pieces. I included patterns like 1010 0101. It takes me a couple hours to get on my feet in the morning, but when I do I will try to locate my file about this.

Hi @john-nz,

   Apologies if you have already considered this suggestion, which is on the borderline of your question.

-----------

RE: The trap needs to be visited quickly if there’s an animal present ..

  You might like to consider the effect of the whole system failing to report an animal being trapped, for any (technical) reason (e.g. battery or component failure). Your consideration would probably include the probability of this happening and the severity of the consequences if it happened.

In the event that you are concerned about this happening, then a possible amelioration strategy could be for the "trap end" to also 'wake up, check and report status' on a timed basis. Then, the "receiver end", could raise the alarm if it hadn't received an expected status update.

By choosing an appropriate time interval between reports, you could be confident that a trapped animal would be notified within an 'acceptable' interval.

---

Just a suggestion, but one that might mean a small hardware change is required, implying it may be easier to implement at an early stage in the development process. Hence, my reason for raising it now.

Best wishes and good luck with your project, Dave

@davee @john-nz Just an FYI, this is called a watchdog, and many/most MPU/MCU have them built-in or simply implemented. Just check specs and samples for 'watchdog'

Ron and DaveE; thanks - very helpful. I'd wondered about what happens if messages don't get through; I'll add that step to the plan.

@john-nz Just a forum FYI, when replying to a post, click the Reply link at the bottom right. If you also want to copy another person, use @davee as an example.

Thanks!  Noted ...

Hi Ron @zander,

   Thanks for the note about 'Watchdog'.

I did know about them, and momentarily considered if they would be helpful, but in this particular application, I don't think they will help. The watchdog is usually a countdown timer that applies a reset when it reaches zero, but in normal operation, the running program is responsible for resetting the counter before it reaches zero.

However, in this application, the description in the opening message included:

When trap activates

• micro-switch turns on the power to the Arduino / ESP32 module

So, until the trap is activated, the processor is unpowered, and hence the conventional watchdog function built into many processors will not be powered either.

Hence, my suggestion of an external means of powering up the processor on a periodic basis to ensure it was still functional.

Best wishes, Dave

@davee Thanks.  I'd wondered about that ... the idea of the trap switching the processor on was to reduce the drain on the battery. In the interests of reliability and the ability to use the watchdog function do you think I'd be better to have the device go into deep sleep and awake either when the trap is activated (hall switch?) of periodically to report in to base? 

@davee @john-nz Man I blew that big time. I should have re-read the original post to determine the parameters of operation but I didn't and somehow assumed a totally different scenario.

What John needs is a wake up service. There are quite a few that all look fairly similar but Dave has one that also includes a complete solution to powering the wake up device via a modified USB power cable.

One improvement that can be made now is changing the ZS-04/DS3221 with a Chronodot. I just got 8 from AliExpress and they were upgraded at no charge to DS3231 Ver 3 that now has EEPROM if you need it. Total delivered cost for 8 was $17USD

@davee

Ron said "What John needs is a wake up service. There are quite a few that all look fairly similar but Dave has one that also includes a complete solution to powering the wake up device via a modified USB power cable."

Can you explain what Chronodot is, and what the solution you're developed is?

@john-nz Chronodot is a brand name for just the DS3231 which is a battery operated Real Time Clock. I will be using them to wake up my remote cameras. The solution Dave developed is fully documented on the forum, I just don't know where it is any more but try searching the forum on DS3231. His solution uses a ZS-04 board that has a DS3231 on it but the board needs some desoldering, trace cutting and I think that is all, whereas the Chronodot is just the DS3231 chip plus needed support components. Here is the AliExpress link LINK  and here is the USA creators web site LINK

I am attaching the pdf of Daves solution, this one uses the butchered ZS-04, the Chronodot is a simple drop in replacement.

Hi @john-nz & Ron @zander,

   I previously wrote the description of a short 'feasibility study' I did about using a real-time-clock (RTC) chip to power up a processor. The suggested scheme was that each wake up would be responsible for setting the time of the next wake up. Hence, the time between any two wake ups could be varied from a few seconds to nearly a month.

My study report can be found at:

https://forum.dronebotworkshop.com/?wpfs=davee%20rtc

I should say, I personally have not spent any further time on this project, as it was really aimed at trying to assist others, and so all my comments in that article and below relate to memories from that time of about a year ago. The marketplace may have changed since then.

The chip (DS3231) is available as a part, but also conveniently on cheap PCBs. My testing used perhaps the most commonly available board, which was conveniently available from a local (UK) Ebay supplier, as well as the better known outlets. Ron is referring to an alternate board called Chronodot.

I leave Ron to describe the Chronodot in more detail, as I have only seen photographs on the web of it, and I can't comment on any direct experience. Both boards are mainly the same chip, so I would hope it is possible to use either, with equal success.

The board I bought required removing at least one small component, so at least a soldering iron, or better still a hot-air soldering station, is probably required. I don't know if the Chronodot will require any soldering.

If you are interested, have a look at the report. It is based around the Raspberry Pi Pico (and hopefully applicable to Pico W), but it should be adaptable to other boards with similar power requirements. I'll try to answer any questions, bearing in mind I do not presently intend to develop it further, and I am not guaranteeing future support.

---------

Ron mentions powering via the USB socket. Hopefully my report will be clear, but to clarify, it is common to develop code using a USB lead between the processor board and a PC, with power for the processor board being provided by the PC, as well as using the lead for downloading the programme and serial monitor communications for debugging. However, when testing a program that affects the power to the processor it is running on, it can become a little messy whilst developing the code. Hence, I include a circuit of switching the power source, whilst is used whilst it is connected to the development PC system. The final system, [with the microcontroller already programmed whilst connected to the development host,] would not use the USB port.

----------

You mention looking at deep sleep of the 'main' microcontroller. I haven't personally designed such a system, but I am aware of a few others that have been down that route over the last 15-20 years, with different microcontrollers. Although, it has been featured in many microcontroller datasheets, and a common theme is that it is not as easy and trouble free as the datasheet suggests.

My RTC study was based on the admission by Raspberry Pi that the Pico had limitations/problems with the sleep function that they had not completely solved, whilst @byron, wanted to use the Pico W board, but not get tangled in a sleep system that didn't work properly, so he suggested completely de-powering the board, and using an RTC to wake it up again, thereby sidestepping the issue.

Of course, your experience might be better than the few experiences I have come across. Bear in mind that you may not find much example and library software to support the different sleep modes, so be prepared to program at a 'low level', possibly even touching assembler level. (I haven't tried looking for such code, so this is just a suggestion to check it out, before deciding to go down this rote.)

----------

Best wishes and good luck with your project, Dave