Readings not coming in
Posted: 19 January 2010 01:22 AM   [ Ignore ]
Newbie
Rank
Total Posts:  9
Joined  2009-09-13

We have created a mechanism to pick out readings that belong to a particular job (we can create jobs and assign a device and a geofence to it). This mechanism runs after the readings have entered the app database. A background task runs and looks at the readings table (much like the notifier), and decides – based on time and geofence – whether that device is part of a job or not. If it is we create a JobReading record, associating that reading with a job.

So – this mechanism runs completely independently of the readings entering our system. It runs after all triggers etc have been fired.

However – what we have noticed, is that once a device enters a geofence associated with a job, the readings no longer arrive regularly 40 seconds apart. They’re spaced several minutes apart - sometimes up to 30 minutes even.

I want to know why the readings stop coming in regularly into our app database. I cannot see any errors in any log files that might show what is going on. Alternatively, I would like to know how the above setup (with the background task that polls the readings table and writes away job_readings records when applicable) might affect readings from entering our system.

Any help would be greatly appreciated.

Thank you
Joerg

Profile
 
 
Posted: 20 January 2010 01:18 PM   [ Ignore ]   [ # 1 ]
Administrator
RankRankRankRank
Total Posts:  249
Joined  2008-12-18

It looks like you’re on the right track. If I understand your question correctly then the system is working as intended. When a device enters a geofence it usuallly stops or idles for a bit. The reporting interval is much less when a device is stopped (once/hr by default). So I can only assume that when your devices enter a geofence they’re probably stopped and won’t report as frequently. Let me know if this makes sense or if I’m misunderstanding your question.

Profile
 
 
Posted: 20 January 2010 01:23 PM   [ Ignore ]   [ # 2 ]
Newbie
Rank
Total Posts:  9
Joined  2009-09-13

You’re right - we do pick up that behaviour too when the vehicle has stopped. But in these cases, the vehicle is moving - yet still the readings start coming in less regularly - sporadically even. What I can’t figure out is why this happens - or where to check if there are readings clogged up somewhere waiting to come into our app database. Or whether what we are doing could in some way interfere with the readings coming in.

Profile
 
 
Posted: 20 January 2010 02:49 PM   [ Ignore ]   [ # 3 ]
Administrator
RankRankRankRank
Total Posts:  249
Joined  2008-12-18

Very interesting. So do you have really large geofences created where you’d expect normal behavior while the device is reporting within the boundaries of the geofence? On average, how large are these geofences?

Profile
 
 
Posted: 21 January 2010 01:20 AM   [ Ignore ]   [ # 4 ]
Newbie
Rank
Total Posts:  9
Joined  2009-09-13

The vehicles inside the geofence work in it - so they spend about 2-4 hours driving around inside the geofence.

Profile
 
 
Posted: 21 January 2010 03:18 PM   [ Ignore ]   [ # 5 ]
Administrator
RankRankRankRank
Total Posts:  249
Joined  2008-12-18

Are you using Enfora devices? If so, this has very little to do with the fact your devices are inside a geofence. The way Enfora devices are programmed is to report based on distance and not time. While in motion the Enfora is configured to report every 600m (or something close to that). Therefore, when in a confined space you’ll see less frequent reports. This is a function of the device and not the application. If this is the case, then I’d recommend discussing this with your account rep to determine next steps. If you’re not using Enfora then ignore everything I just said and let me know what device you’re using.

Profile
 
 
Posted: 22 January 2010 01:12 AM   [ Ignore ]   [ # 6 ]
Newbie
Rank
Total Posts:  9
Joined  2009-09-13

Yes! We are using Enfora devices. I think this could be it. As in and out of the geofences the readings come in regularly - as the vehicle is driving at a normal speed. And once in - in tends to drive very slow. Thank you for your help.

Joerg

Profile
 
 
Posted: 22 January 2010 04:19 AM   [ Ignore ]   [ # 7 ]
Newbie
Rank
Total Posts:  5
Joined  2009-11-30

i am not sure that this is the reason Camps Bay has a Coverage area of 65000 square meters the tractor width is 2,5 meters on average the start time is 5 oclock and the finish time is 9:30 a snail trail would cover the whole area.
On average we know that the reading come in 1m17s the average job is 4,5 Hrs there is 270 min in 4,5 hr,  this based on an average speed of 30 km n we dont clean camps bay beach at 30 km we clean at 15 km we would cover half the area that means 135 min which you divide by 1:17 therefore there shoud be 115 Blips,

I do agree when it is going very slow then it should have a lot less blips sbut we are only seeing the hrly blip and no distance maybe the script is not recognise distance travelelled but time travelled

It seems once it enters the jobs geofence only the hourly reading comes in

Profile
 
 
Posted: 22 January 2010 09:45 AM   [ Ignore ]   [ # 8 ]
Administrator
RankRankRankRank
Total Posts:  249
Joined  2008-12-18

Very strange. When you say hourly reading what are you referring to? By default, we configure Enfora units to report once/hr when stopped. Is that the hourly report you’re seeing or is it a different one? Also, have you changed the default configuration of the Enfora devices?

Profile
 
 
Posted: 22 January 2010 01:32 PM   [ Ignore ]   [ # 9 ]
Newbie
Rank
Total Posts:  5
Joined  2009-11-30

It is the standard hourly reporting that has been set up by your developers for the enfora unit,

Profile