Driver’s review of Rand McNally ELD will make you chuckle … and maybe pull all of your hair out
CDLLife reader, company driver, and former tech writer Jim March Simpson sent in a product review that manages to be incredibly thorough on the technical details while also making us laugh. Enjoy!
——————————————————————————————————
A Review of the Rand-McNally ELD system – DS200 communications device, TND-740 tablet.
This “review” will be different than most. I’m a company driver for a small fleet of about 125 trucks. Due to a past life as an IT/Sysadmin/Techwriter I was roped into doing a beta-test of two different ELD devices. The first I won’t go into in detail (or even name them) – it was an annoying but workable system from a smaller vendor.
We had high hopes for the Rand-McNally solution. They have a stellar reputation in the trucking industry for paper and electronic maps, and we assumed their ELD system would be a winner.
Short form: like hell it is.
The DS200 is the device that plugs into the truck’s electronics, sits on the dashboard and provides WiFi to the tablet running ELD software, in this case RM’s TND-740.
This “review” is going to take the form of a series of Emails I sent to my bosses, in the order in which I sent them. I’m not going to name my company but I will provide CDLLife with the contact info for my bosses so they can confirm that this is real. This first message will show that I was not in any way biased against this system:
Jim March Simpson <1.jim.march@gmail.com>
Mon, Oct 2, 2017 at 2:58 PM
To: <Bosses>
Subject: New Elog finally coming in?
BOSS IS GETTING ME,
A RAND MCNALLY!
SLAP IT IN MY TRUCK,
JUST AS PRETTY AS A SALLY!
GIMME THAT MAPPER AND YOU’LL BE MY PALLY!
BOSS IS GETTING ME,
A RAND MCNALLY!
?
Jim (your favorite lunatic geek trucker)
OK, so I’m a bit of a goofball. I still took the task of evaluating this critter seriously. One other thing: once I got the RM system and did real testing, I did NOT use it as my official log. I’m still legally on paper and am using the KeepTruckin’ “paper equivalent” Android app for my real logs.
Jim March Simpson <1.jim.march@gmail.com>
Sun, Oct 8, 2017 at 11:25 PM
To: <Bosses>
Subject: Rand McNally (“RM”) ELD report #1
Gents,
I hope you share this with RM sales guys.
The short form is, it’s in far better shape than <other system> and is usable right now. There’s issues but I think they can be addressed via a small “user guide” customized for [company] drivers on a laminated card about 6″ by 4″ or so. I could write it. That’s worst case. Best case, RM fixes most or all of it and we don’t have to.
I’m going to number each issue, plus they’ll be in “categories”.
User interface issues…
1) Getting to the home screen from within the ELD system involves the standard Android back button. From the mapper you use a “nine dot grid button” in the bottom right corner, probably left over from the pre-Android devices. No standardization. Ooops. “How to confuse newbies 101”.
2) Inside the ELD app there’s extensive menus under the three horizontal bars, top left corner. This isn’t obvious to users new to Android which will describe a lot of drivers. ELDs will cause frustration. Adding to it may cause somebody to pitch it out the window at 70mph…
Workflow within the ELD system…
In general it’s very good. On coming to a stop for example I can select off-duty, sleeper berth or an on-duty fuel situation easily. I can do an on-duty with pretrip in the morning no problem. However…
3) Starting a pretrip doesn’t automatically start the DVIR process. It should. Best bet would be a new button next to the OFF, SB, D and ON buttons called “Pretrip” that would set up on-duty, pretrip PLUS engage the DVIR subsystem. (Another such button marked “FUEL” would also be nice and should fit just fine…)
4) For some reason once I park and engage sleeper status I cannot go in and edit the comments line to show that it’s both a sleeper and quick posttrip inspection until that sleeper session is ended. Very odd. I guess RM assumed we’d log 5min or more on-duty time marked “post trip inspection” in the comments, then go off-duty or sleeper berth?
5) Just in general, under the comments for any duty status we should be able to select commonly used comments from a pull-down menu.
Misc…
6) What exactly triggers driveline status, and can we customized it? It appears to be engaging at 15mph or so? If so we can survive that. Distance-based is better I think?
7) A real oddity…we can’t set it to indicate a given truck is a daycab and therefore turn off sleeper berth mode. <Company> might one day buy a daycab and hire a local guy to do local stuff only. For all I know we maybe have one already?
8) Just a <company> policy thing…drivers need to be told not to replace the RM charge cable with a cheap truckstop Chinese USB charger if they break or lose the RM charge cable. Some of those truck stop chargers are just horrible as far as putting out clean 5v power. Put a spare cable setup with the fuses in the zip-up truck manual bags maybe?
9) <Boss> sent me a message in the RM system. I never got it (and I did find the messaging subsystem). I saw a reference to a subscription needed maybe? If so can we be set up to test messaging?
10) If we do a lot of system updates, will that eat into our available data usage over the Sprint connection?
Thanks,
Jim Simpson
A comment: to this point I was using the RM ELD system as if I was a trucker trying to be legal and use the system as intended. I then began testing as if I were lazy or trying to cheat, which I could do since this wasn’t my real official log…and that’s when it started to go VERY wrong…
Jim March Simpson <1.jim.march@gmail.com>
Tue, Oct 10, 2017 at 9:22 PM
To: <Bosses>
Subject: Rand McNally (“RM”) ELD report #2 (Bad Trucker edition)
Today I tested what would happen if a driver completely ignored the RM ELD all day long. I did so, with all of the RM parts turned on and the 740 showing map functions on screen. I was looking for two things: would the ELD app alert me as to violations, and could I edit everything and make it all legal at the end of the day. (I did of course run Keeptruckin on my own tablet and did NOT actually do anything REMOTELY illegal.)
What I found was…well, disturbingly bad.
Sigh.
1) At NO time did the system alert me to trouble during the day. Nothing. Now, I had the sound turned down so maybe it did audio alerts. I’ll check that tomorrow. The main trouble during this test is that each time I parked I allowed it to roll over from drive status to on-duty, which meant no 30min break. I wasn’t warned of this. This is a major, major problem.
I suspect what’s happening here is that the mapper isn’t a native Android app. It’s still using code from the pre-Android RM mappers like the old 525/725 family, running in an emulator sandbox or virtual machine of some sort. This prevents the ELD app from writing to the screen while the mapper is running. If I’m correct, fixing this may be impossible short of porting the mapper app to native Android.
2) During the editing process I could go into the log and find each item in blue that was an on-duty event. Each had a location listed as you’d expect. But the moment you switch an event to SB or OFF modes, the location vanishes. Unless you remember it or write it down or something, it’s lost. You can do a select-copy-paste operation but only somebody who really knows Android will be able to do that and it’s annoying to do it every time.
This should be an easy fix.
I was at least able to insert a pretrip period before the first driveline event. That’s good. But doing so doesn’t prompt you to do a DVIR, and it should. Yet again, a single “pretrip button” could control all of this easily. Put it right next to the fuel button…
3) There’s no alerts that you don’t have a DVIR in place, although I’ll double check this tomorrow morning… It might complain about yesterday’s logs missing DVIRs? More on this later.
Conclusion:
As long as you use it right it works fine which is why my first days usage had me very positive on the system. What I have learned today however is that if you use it wrong or the driver makes mistakes the system fails badly to either catch the drivers mistakes or easily allow the driver to fix the mistakes at the end of the day or at least after the fact in some form. This points to a lack of usability testing in the hands of real truck drivers who really use ELDs and have experience with ELDs.
Bug number two and number three above look easily fixable but number one if I’m correct about the cause may be structurally fundamental to how this combination of parts and software works. The only fix may be to strip out the map function in the 740 and make drivers get their own separate mapper.
That won’t be popular. I really wish I had better news.
I’ll re-test tomorrow with the volume up and see if there’s audio alerts to logging/hours errors. I hope so. But even then a pop-up error on screen that the driver has to acknowledge would be far better.
One more thing. For <company>’s type of trucking it would be really awesome if on parking the ELD would roll over from driveline status to off-duty instead of on-duty, or better yet 5 minutes of on duty and then roll to off duty automagically. We are a dryvan live load company and therefore we don’t do a lot of work on site other than check paperwork, back into a dock and go to sleep or hang out online or whatever. We only use on-duty to fuel and pretrip. This change would make using the ELD a joy, and close to foolproof for us. Ignoring it all day would actually work except for recording fuel stops.
Tomorrow I’ll do more “bad trucker” stuff including disconnecting the DC200 to “attempt to cheat”, plus audio alert tests, etc.
Jim Simpson
Jim March Simpson <1.jim.march@gmail.com>
Sun, Tue, Fri, Oct 13, 2017 at 11:54 AM
To: <Bosses>
Subject: Rand McNally (“RM”) ELD report #3 (follow-up to previous issues)
This message is CCed to Rand McNally support.
1) On Wednesday I did some testing to confirm some of the issues in report #2. I drove all day in “bad trucker mode” yet again, ignoring the ELD software, but instead of running the Rand McNally mapper application I ran the gauge package which appears to be an Android app. The ELD/logger system WAS able to pass errors/alerts to the gauge screen.
This, to me, confirms my theory that the mapper app isn’t a native Android app and this is why the ELD system cannot write errors (“8 hours almost up” and the like) to the mapper’s screen. If so this is a fundamental “structural” problem that will be hard to correct without re-writing the mapper app to Android.
2) In a phone call with RM support today they confirmed all of the issues from report #2 in this series. Yes, the mapper app blocks ELD alerts. Yes, the DVIR alert system is questionable, although they did show me an easier way to get to the DVIR workflow process. They assume a “morning pretrip” process as the place the DVIR goes (which is also what <comany> does now, so that’s good) and with a minor “getting started” cheat-sheet document (laminated 4″ by 6″ card or the like) we could get that message to the drivers. I could write such a document and be a tech support resource internal to <company> if needed.
3) They agreed with me that destroying the location data on a previous on-duty event that a driver is now changing to OFF or SB later in the day is bad news. They point out that there are internal records showing each edit but that doesn’t help a driver by the side of the road being screamed at with guys with guns and bad tempers
Sigh.
I can keep testing, and I will, but…I’ll be honest. These problems are just…severe, esp. the lack of alerts while in map mode. Drivers coming from paper will be able to cope but those coming straight off of major fleets and Elogs will be screwed, and that will be where most of your new drivers come from (like me, to be honest). At this point my recommendation is against RM. Sorry, but…ye Gods it’s problematic (as an ELD, and the mapper is surprisingly bad!). I’m hearing that Keeptruckin’ has fixed their earlier issues and we should maybe give that a try
As an aside, their review of a similar RM product says basically what I’m saying about the clunky user interface but doesn’t talk about some of the more serious bugs such as deleting location data when editing an on-duty event to SB or OFF, or the lack of rolling alerts to hours of service issues while mapping.
Jim Simpson
Jim March Simpson <1.jim.march@gmail.com>
Thu, Oct 26, 2017 at 3:28 PM
To: <Bosses>
Subject: RM Report #4 – GOOD NEWS FOR A CHANGE!
I’m CCing David <a Rand McNally support staffer> as this is, in large part, a follow-up to my phone call with him today. It was a very productive conversation.
1) Alerts – David has confirmed that alerts to the driver are not being pushed to the driver through the mapping screen right now, and that the cause is the mapper being a non-Android app running in emulation. The good news is a fix is in progress and is planned for release before Thanksgiving. Other fixes include alerting the driver to problems with the DVIR and other such things I’ve caught. It appears they’re going to fix all of the “not enough info for the driver” issues I’ve seen so far. This is good news.
2) David was able to set the speed limit for dock moves from 5 miles to 15. This will help a lot. Setting a 2mi distance limit is likely not going to be legal. I’ve lived with a 15mph limit for a year and it’s…annoying but survivable.
3) They know about the log editing issues and that’s also planned as a fix before the mandate.
4) David says he can set it so that when I stop it will default to SB status!!! That will make this BY FAR the easiest ELD to use bar none for our type of live-load dryvan trucking! It might require a small software upgrade if we implement it company wide? David is going to set it up so I can evaluate it by tomorrow. If it works…we see what it costs. If it cuts down on the support calls like I think it will, it’ll be worth it.
5) Right now drivers can attempt to cheat by turning off the DC200 and 740, drive for however long and then start it all back up. They will get no alerts that the odometer has crawled upwards in an unexplained fashion. David says a monitoring screen at <company> safety will catch it. The updates planned before Thanksgiving will give the driver an alert, AND will push a “DC200 not responding” type of error to the screen (even when the mapper is up, I hope?)
However I do have one concern about this. When my DC200 crashed, rebooting it by physically unplugging it was the only cure I could come up with. At other companies (megacarriers) where I used ELDs it was a firing offense to disconnect an ELD and the cable connection wasn’t easy to get to like it is on the DC200. IF DC200 crashes and reboots are common enough, some ethically challenged drivers will use “oops, had to reboot it, sorry boss!” as an excuse to try and cheat.
<Company> will need to let drivers know that “mystery miles” WILL be detected. That’s part of what I think we’ll need a quick-reference card for
I’ll continue monitoring the stability of the DC200.
QUESTIONS FOR DAVID <RM support staffer>:
1) There’s a reset button hidden on the DC200. I do NOT plan on poking it with a toothpick! But…what would happen if a driver does?!
2) How often does the DC200 crash and need a hard reboot?
3) Can you confirm that “I lost contact with the DC200, check it out or reboot it” or something like that will be an alert that will be passed to the driver soon even if the mapper screen is up, in an upcoming update?
QUESTION FOR <BOSS>:
This morning I did a “cheat test”. Just before 9am Central I disconnected the DC200 and powered off the 740. I then drove just under 5mi to my drop from a small truck stop. I then did the same thing back to the truck stop about 1hr later. Can you see what your monitoring screens show?
Thanks guys!
Jim Simpson
RM support provided no answers to these or other questions, nor did they make the promised change to auto-switch to off-duty on parking. They also didn’t appear to fix any of the major bugs and glitches we found despite two updates to the ELD software.
As of Nov. 20th 2017 my company gave up on RM as a solution and I gave back all the hardware on Nov. 21st
My company also evaluated the Keeptruckin’ actual legal ELD setup before I got involved and rejected it in part because, like RM, they’re overly reliant on standard Android user interface pieces that aren’t obvious to somebody new to Android. A lot of the truckers currently on paper logs have no clue how Android works. I suspect that this mistake is going to be repeated by any number of ELD vendors.
RM’s ELD problems however are more severe than most and will definitely get some truckers in trouble. The fact that an ELD system by a company with RM’s reputation is in this bad a condition with less than a month to go before the mandate hits tells us the ELD industry simply isn’t ready yet, and that the FMCSA has done a terrible, horrible, disastrous job monitoring the ELD vendors to make sure they’re shipping usable and legal products.
PS: there’s one more bug I didn’t get around to reporting. If the DC200 and TND-740 are both fully powered down (such as will happen if a shop has to disconnect the truck’s batteries), on power-up of both the TND-740 won’t auto-reconnect to the DC200 and hence no logging will occur. You have to go into the ELD software function on the TND-740 to get it to reconnect to the DC200. The bug here is that the ELD software isn’t being automatically started up on device power-up. Pure idiocy – if a driver happens to start up without filing a DVIR after a shop stay, their whole day’s activities will be up in smoke.
It’s as if Rand-McNally wants their customers to get in serious legal trouble with guys with bad tempers, badges and guns.