Thursday, June 9, 2016

Buglets

Buglets

I spent a fair amount of time writing code when it wasn't convenient to test it right away.  As a consequence, I had a pile of stuff to test the other night, and ran into a gazillion little buglets. Everything, so far, has been pretty easy to fix.

Watchdog Timer & Supercap charging

I implemented a watchdog timer, and sprinkled calls to refresh it throughout my code. Later, I implemented a routine at initialization to assure that the Supercap is charged up beyond a certain voltage before allowing the code to proceed.  The first thing we do is turn on the GPS, and I envisioned a situation where the GPS would brown out, repeatedly, as we're trying to charge the supercap and get going.  Well, I added a routine that was basically like this:
volts = getvolts();
while (volts < 3500) {      // Keep charging if less than 3500 microvolts
   deepsleep(5);        // Hibernate for 5 seconds
   volts = getvolts();
}
Well, the code worked a little too well.  I forgot to add a line to refresh the watchdog timer in the middle of that.  My timer pops after about 14 seconds, if it isn't refreshed. The entire board was rebooting during the charge-up phase.  It was a simple matter to call my "WATCHDOG_REFRESH()" macro to the middle of the loop.


GPS Reset

A few people running Pico trackers have had problems with the GPS freezing up, and basically not working for an entire day, until the sun went down, and the board rebooted overnight.  I added counter to keep track, and reset the GPS if it takes "too long" to get a lock.   

While I was testing something else, I left the tracker running on my desk.  I turned later, to find that I had exceeded my "too long" threshold, and the tracker had reset. Unfortunately, I neglected to reset my counter in the GPS Reset routine, so it kept getting called over and over, once the time was exceeded.  It was a simple matter to zero the counter after the reset.


Geofencing default

In testing my geofencing code, I discovered that the default if a coordinate was not in one of the polygons was "not allowed".  I found a #define in the code I had borrowed, and changed the default in my test environment.  Unfortunately, I forgot to port the one-line "#define" line into my Eclipse environment.  So, the geofencing in the code "worked", because it got back a "not allowed", and didn't transmit.


Revenge of geofencing

Well, I thought I fixed it, but I didn't.  I ran into another issue.  The geofence routine returns "true" if you are allowed to transmit in the coordinates passed to it.  I was setting a variable called "fenced" to the value of the geofence subroutine.  I basically had the value backwards.  I had to reverse the returned value from the call to make it behave as expected.  


Oversleeping

My deepsleep() routine always seemed to sleep about 1 second too long.  I didn't worry about it, since I was waking up the GPS 30-45 seconds before transmit time, and the one second didn't matter.Well, when I added the watchdog timer, I had to modify deepsleep() to sleep in 5 second chunks, and wake up to reset the watchdog.

Well, long story short, it turns out that the HAL routine to sleep is 0 based.  So, to sleep for 1 tick, you call it with a "0".  So, when I called it with "5", it actually slept for 6 seconds.  

In the original code, this wasn't a big deal.  No matter what length of time I intended to sleep, I just slept one extra second.  However, when I broke my sleep into 5 second intervals (which were really 6), the problem multiplied. 

Another easy fix.  Just subtract 1 from the sleep time, and voila, it worked much better

WSPR transmit DT


During testing, I noticed the DT column showed that my WSPR packets were about 2.4 seconds off my laptop.  I was pretty confident that I was syncing to GPS right in the tracker.  Upon conversations with Alan/W7QO, I was reminded that the WSPR protocol calls for the transmission to start at 1 second after the even numbered minute, not at 0 seconds.  That accounted for one second right there.

I'm still chasing the other 1.4 seconds of error.  It could well be my work laptop is not well synchronized to GMT.

No comments:

Post a Comment