Yes that is basically what I was saying only flipped around... I was converting degrees into meters and then doing Pythagorus to make it a circular distance rather than a square... whereas you are converting meters into degrees and just using a square... so yes perfectly good approximation for what you are doing. Only change I would make is that the longitude distance should be factored by cos of the latitude to make it a truer square (as the lines of longitude get closer together as you move towards the poles so 1 degree is a shorter distance the further north you are)
TinyGPS++.h have this special function.
double gps::distanceTo(double lat2, double lon2)
{
distance = tGps.distanceBetween(tGps.location.lat(), tGps.location.lng(), lat2, lon2);
return distance;
}
Just another thought, if your last location you sent to the backend is less than 200m from where you stop and is going to be stationery for a while, you are never goin to report it.
Say you are on route home, you are still 150m from home and you send a location, you next location is home, you will never report you are home.
We also with LoRaWAN encode our data, this is so you sent the min amount of date, min amount of air time and then you save on battery, in your case with a powered GSM device you will save on data.
Encoding
LatitudeBinary = ((tGps.location.lat() + 90) / 180.0) * 16777215;
LongitudeBinary = ((tGps.location.lng() + 180) / 360.0) * 16777215;
txBuffer[0] = (LatitudeBinary >> 16) & 0xFF;
txBuffer[1] = (LatitudeBinary >> 8) & 0xFF;
txBuffer[2] = LatitudeBinary & 0xFF;
txBuffer[3] = (LongitudeBinary >> 16) & 0xFF;
txBuffer[4] = (LongitudeBinary >> 8) & 0xFF;
txBuffer[5] = LongitudeBinary & 0xFF;
altitudeGps = tGps.altitude.meters();
txBuffer[6] = (altitudeGps >> 8) & 0xFF;
txBuffer[7] = altitudeGps & 0xFF;
int speedGps;
speedGps = tGps.speed.kmph();
txBuffer[8] = (speedGps >> 8) & 0xff;
txBuffer[9] = speedGps & 0xff;
Decoder
data.la = ((input.bytes[0] << 16) >>> 0) + ((input.bytes[1] << 8) >>> 0) + input.bytes[2];
data.la = (data.la / 16777215.0 * 180) - 90;
data.lo = ((input.bytes[3] << 16) >>> 0) + ((input.bytes[4] << 8) >>> 0) + input.bytes[5];
data.lo = (data.lo / 16777215.0 * 360) - 180;
data.speed = ((input.bytes[8] << 8 ) >>> 0) + input.bytes[9];
⌠which is why I suggested also adding a time check . ( SIM900 and SIM800L GSM project - #33 by dceejay )
Dave,
Shouldn't your car be blue ?
Couldn't help myself, since you blocked out the gps location, but included the map
This is a copy of an email I've just sent to one of my friends in the USA.
Subject heading was: This suggestion will knock the socks off of you
âYour mission (name hidden), should you decide to accept it is to... (read on) â
âThis email will self-destruct in five seconds. Good luck, (name hidden).â
I need someone to help tune my Experimental Vehicle Tracker (codenamed EVT).
This can be done remotely as you will understand shortly.
The first step is for me to provide you with the secret code to access my SkyNet communication system.
Next step is to establish verbal (and maybe visual) communication between us.
Now for the critical part...
As you know I can send readings from my GPS module via the GPRS/SIM900 module to BeeBotte and hence to Node-RED. I can also send commands from Node-RED via BeeBotte to the GPRS/SIM900 and then onto the Wemos D1 Mini. At the moment I am just turning a blue LED on/off - pretty tame I'm sure you will agree (???)
With a tiny modification I reckon I could send a "number" and a "fraction" - - "WHY" - I can hear you ask.
Well... the answer is... the number could be used to control the 'sampling-interval' for the GPS module and the fraction could be used to set the 'displacement' for the space between one geo-fence and the next one.
I'll wait a for a few minutes while you pick yourself up and put your socks back on - as the above must have been a shock for you!!!
So it will be just like controlling an F1 Racing Car from the pits using Telemetry.
Only difference is... I haven't got an F1 Racing Car - BUT I do have a hybrid car which you will have to accept as the next best thing.
So this is how I see it working...
YOU will be the race director and I'll be the racing driver.
Assuming we have two-way communication and you have a Node-RED dashboard showing my World Map node I will start my engine.
As I proceed on my journey you can watch my progress on your Node-RED dashboard in the US and make adjustments to the "sampling-interval" and the "displacement" value and see how that affects the results. Via the "comms" channel you can give me feedback as to what is happening to the GPS sensor.
What do you reckon???
What a hoot that would be???
What a great story to tell people at Christmas??
I would ask my wife to accept this mission BUT she thinks we are just kids playing with our toys - so I can predict what her response would be immediately!!!
I hope you decide to accept this mission (name hidden).
Kind regards, David.
Thanks for the various inputs from people about how to improve my Vehicle Tracking system.
I've taken a slightly different approach in respect of detecting if a vehicle has stopped or moved off within a virtual geo-fence/box area. This should also cater for the situation flagged up by @ScheepersJohan ...
"Say you are on your route home, you are still 150m from home and you send a location-report, your next location is home, you will never report you are home."
As shown below, I've implemented a falling-edge and rising-edge detection in respect of the vehicle's speed.
Note: prev_speed
is initially set to 999.0
// Check if vehicle is still in the geo-fence box
if (myLat >= lat_min && myLat <= lat_max && myLon >= lon_min && myLon <= lon_max) {
SerialMon.println("Vehicle hasn't moved, so nothing doing");
// Check for falling-edge == vehicle coming to a stop
if (prev_speed > 0 && current_speed == 0) {
SerialMon.println("Vehicle has come to a STOP");
prev_speed = current_speed;
read_and_publish_gps_values();
}
// Check for rising-edge == vehicle is starting off from stationary
if (prev_speed == 0 && current_speed > 0) {
SerialMon.println("Vehicle is starting off from stationary");
prev_speed = current_speed;
read_and_publish_gps_values();
}
}
Just been out for a test-drive and can report the 'idea' seems to work.
Here's the detections for backing out of the drive and arriving back home.
I stopped here (black icon) for 21-secs to check the falling-edge detection. (rows 248 and 249 in the dB)
In this view my car is travelling from bottom to top of the image. As you can see I stopped for a short time (black icon) then moved off (blue icon) detected by the rising-edge in the code. Row 258 and 259 in dB.
Here's what the data looks like in my dB.
Please note - row 252 and 253 is where I stopped and reversed into a parking bay.
At the moment the sampling_interval
is fixed at 15-secs (which was the value I calculated for a vehicle to travel a 1/4 mile at a speed of 60mph). I reckon I could reduce that value to just a few seconds (maybe 4-secs) as I'm now using the virtual geo-fence/box method to determine movement and speed.
SIM800 and breadboard with jumper wire always haunt me in dreams.
I prefer short distance solder point!
Don't worry - I'll be designing a PCB once I've completed the prototype - so you can sleep well again.
PS: I once ran a training course in Pune for CoreEL Technologies - way back in January 2000.
Eager to see PCB!
Here's a link to a selection of PCBs I've created (and posted on the forum).
https://discourse.nodered.org/t/another-set-of-pcb-designs-for-wemos-d1-mini-and-esp01-s/52770
https://discourse.nodered.org/t/another-set-of-pcb-designs-for-wemos-d1-mini-and-esp01-s/52770
Comes up as Oops! That page doesnât exist or is private
Oops - sorry - posted a link to a private area.
Here's are some photos (same as what you would have seen if the link had worked).
Sometime ago, I wrote a GPS track filter based on time, distance, speed and heading -here-. Taking the last reported time, coordinates, speed and heading from the GPS chip, then calculate an assumed position based on that data at the current time. If the current location fails outside of your tolerances (time, distance, or track), then re-report the location.
I like your efforts. But, I'd like an affordable GPS tracker that plugs in to the car power port and has both LoRaWan and Wi-Fi. LoraWan only supports short binary messages (30 seconds/day of transmission) but if we used some kind of disruption tolerant networking we could sync the entire route when in range of Wi-Fi.