Hudly is a new full-colour heads-up display system that’s raising funds on Kickstarter right now so that it can go into mass-production later this year.
It comprises a projector unit and a glass ‘combiner’ which is used to display the full colour projected image in front of the driver.
DigiHUD, like other smartphone apps, works incredibly well with Hudly and we were so impressed to see it in action.
Hudly also connects to the vehicle diagnostic (OBD2) port to show information right from the ECU, like fuel quantity remaining, engine revs, outside temperature, mpg etc.
It’s recently been featured in the press, including TechCrunch, TopGear, Stuff.tv and GadgetFlow.
DigiHUD is proud to be a backer of Hudly. The Kickstarter, which tells you everything you need to know about Hudly can be found via this link.
Update: To help raise awareness of the campaign, the free version of DigiHUD now includes a simple popup which links directly to the Kickstarter. This one-time popup is shown the first time HUD mode is selected. It’s also available from the Menu.
I’ve swapped out the head unit in my new car for a brand I’d never heard of before – AutoPumpkin. It’s relatively low priced yet has plenty of features and connectivity options. I bought it because the unit that was in the car (a JDM Clarion) was a CD and Mini Disc player, but only Japanese Mini Discs..
I also wanted a DVD player to play movies on the rear roof mounted screen to keep the youngsters happy on long journeys. Having one that runs Android was also a win because I can run DigiHUD on a larger screen than my Galaxy S3s, and it just comes on automatically so no need to set it up when going for a drive. I play music over Bluetooth which can be controlled by my phone.
I plan to install a couple of blind-spot cameras later on which can be fed into the Pumpkin. It doesn’t have DAB radio (separete module is available) and the AV out is only for the DVD but overall I’m very happy indeed with the unit.
If you plan on using this app to give you accurate readings that you need to rely on for some reason then calibrating the device or comparing it with a calibrated device is essential.
DigiHUD app doesn’t know how accurate the GPS data is that it receives and doesn’t make any allowances for inaccuracies in the data. All the app does is display what the (usually cheap, low-cost, low precision) GPS sensor is telling it to. So if the sensor is inaccurate then the app will be too.
I use the app every day (well, every car journey actually) and because I use a high precision GPS receiver, and also because DigiHUD matches exactly several local roadside speed warning signs, I’m very comfortable that the speed I’m travelling is accurate enough for me. If the accuracy was unknown then I’d be uneasy travelling on the speed limit.
So please remember the following, taken from the app’s Help text:
Although we strive to make all readings as accurate as possible they are only as accurate as your device’s sensors and should only be regarded as approximations.
I saw a review of the free version of DigiHUD today that mentioned the maximum value of the trip counters. Here’s Ryan Scott’s review:
Really like this app and use it exclusively to accurately log mileage on my Dodge diesel to track mpg’s. I only give it 4 stars due to trip meters only reading in the thousands. I would consider paying for the pro version if the trip meters read higher.
I realised that it’s not in the description or the app itself what the maximum values are, for either the free or Pro version. It’s impossible to put everything that the app can do into the description because of the character limit.
Putting it all in the app itself is either too late (because it won’t be installed if you don’t know about some ‘killer feature’) or it just won’t be seen. Nobody wants to read a huge pile of text about what the app can do or how to use it, I get that, and apps should be intuitive and not need instruction manuals. You probably don’t want to see a huge window open when you start the app listing its features and giving instructions on how to use it.
Here’s a Pro screenshot showing how the values can be set to show greater precision and also the number of digits the trip counters can have. That’s a million miles/kilometres.
Trip counter showing optional leading zeros
It’s worth mentioning that the free version also shows some values to two decimal places when in landscape view.
Do you have any video of how you use DigiHUD? Have you video’d something really cool you used DigiHUD for, like finding the top speed of a model aircraft or RC car?
I’d love to see them and also create an interesting short video for the Play Store listing.
Please email the address in the app listing, of fill in the Contact Form if you have something you want to share.
I knocked it off the kitchen unit onto the hard kitchen floor tonight and now it’s dead. Doesn’t power on or flash. Nothing.
I’ve tried everything I can think of to revive it but it’s showing no signs of life. There’s nothing rattling inside and it shows no visible signs of damage but even after popping the battery or charging on the USB cable it’s DOA.
Immediately ordered another one as I can’t bear to use the app without it.
I plan to get a video of two phones side by side in a car with one running the internal GPS receiver and the other running an external receiver but for now here’s a short video of the Pro version in a test mode, taken using screen capture.
It shows the difference in update speed very well but because it’s not in a car where you can see the road for reference it doesn’t give a good view of how the lag is reduced.
The test runs continuously from 0MPH to 121 and back to 0.
One thing I’ve really been wanting to try for a while is just how well DigiHUD performs when using a better GPS receiver than the ones built into our devices, and today I got the chance to do just that.
As anyone who has used the app, or similar GPS location based apps will know, phones have very slow GPS location updates, which is shown by the slowness in updating the speed. Try accelerating and watch the app and your speedometer and you’ll see that the app is at least a second or more behind.
Generally the update rate will be somewhere around 1 per second (1Hz) for built-in GPS, and that means that no matter how fast and efficient the app is there’s going to be a noticeable delay between travelling at X mph and the app displaying it. This is partly why I’ve had no interest in writing a 0-60/0-100 timer. The accuracy just isn’t good enough for me to be happy with the results.
To verify the update rate I’ve written a basic test app that times GPS updates and shows the average updates per second and the number of updates for as long as I run the app. Interestingly, my LG G3 was 1.00/sec and my Samsung Galaxy S3 was 1.01/sec, after both received 365 updates.
I took a few quick snaps of the unit itself and the box, but not the included accessories: a USB to Mini USB lead and a Mini USB car power lead.
The GLO in it’s box.
Box detail, showing contents and GLONASS compatibility.
It’s not that big at 75mm x 40mm x 18mm, and weighs about 272g. There’s a USB connector on the side below the power button and the included cables have straight plugs unlike the angled one bundled with my Garmin SatNav.
The unit itself turned on.
Manual, and a penny to show how small the unit is
Underneath with it’s grippy feet.
Set-up for use with Android was painless following these excellent instructions and it was paired with my phone in seconds.
I installed ‘Bluetooth GPS’ from the Play store and configured it as the link above describes. The app can be started/stopped very simply from a widget. It also goes to sleep if the Bluetooth pairing stops.
I could now test it and found that it was averaging just over 7Hz after 1000 updates.
Test app
It’s extremely hot here tonight and I want to try this again when it’s cooler and also outside to see if this makes any difference, after all this unit is capable of 10Hz.
I was able to take the unit for a run out in the car earlier wondering how well DigiHUD Pro would cope with a higher refresh rate. I know the app moves a lot of images around on screen and can get quite memory hungry, especially the compass, even though I’ve tried very hard to manage memory as best I can.
Oh wow. Performance was like night and day! It was so much faster updating and the lag was gone. I was really pleased to see DigiHUD keeping up with the car speedo when accelerating and decelerating. When I slowed to a stop (even quickly), both speeds hit zero at the same time. I was actually shocked at how well my app performed. The graphical compass moved way more smoothly too. It really put a smile on my face!
So it’s early days with the Garmin GLO but from a couple of short tests I’m already blown away by it and will not want to go back to using the phone’s GPS sensor. No thank you! I’m also really pleased with how my app performed, it never missed a beat, although it has shown that I’ll need to change the way the satellite information is deciphered as it thought that GPS was unavailable.
I’ll be leaving a 5* rating on Amazon for the Garmin GLO.
From having seen it happen on my own device I think it’s a big enough issue to warn people whenever possible, hence having a post here about it.
Until I had my Galaxy S3 I really thought that it was problem reserved for CRT screens. I’ve seen many cash machine screens over the years with burned-in screens showing ‘Please insert your card’ or something similar. I think the older green screen monitors were the worst from what I saw.
Anyway, why would modern cutting edge display panels suffer from this? It’s the 21st Century after all. Unfortunately some types of screen do, and badly. Badly enough that I won’t be buying another AMOLED display, as gorgeous as they look with their ultra-black blacks and saturated colours.
After many many hours of testing the app over the last two years one of my devices (a Samsung Galaxy S3) does now show some burn-in, which on a white screen can be seen as a slight yellowing of the display where the speed and other information is displayed. Another older device (an HTC Wildfire) has no burn-in at all. The Samsung has an AMOLED screen whereas the HTC has an IPS screen.
Here’s a rather bad photo (thanks to my LG G3’s camera) of my S3 with a blue screen (the best colour I’ve found to show the damage). The blue is actually very even to look at it’s just the camera failing to work it out. According to Erica Griffin (see link below) it’s the blue pixels that degrade fastest as they consume more energy to power them.
Burn-in damage
See how the digits from DigiHUD are still visible, as well as the status bar which is black for the majority of the time in normal use. This is from using the app for about an hour and a half, five days a week for two years (or thereabouts).
Check your device documentation for more information on whether your device may be susceptible.
<opinion type=”mine”>If you’re suffering from burn-in on an AMOLED screen then PLEASE don’t use any of the apps purporting to remove burn-in. They don’t work, it’s a lie. Degraded pixels can’t be revived. All you’ll do is accelerate degradation over the rest of the screen.</opinion>
Back when I was building the initial app I was using an HTC Wilfdfire, and after that a Samsung Galaxy S3, and life was good. These were the only Android devices I’d used (or seen) and it turned out that these phones were lulling me into a false sense of security – every device has a hardware menu key, right? Wrong.
DigiHUD was always meant to be a full-screen app, with none of the Android furniture like a status bar to detract from it’s purpose in life – to show the information as simply and cleanly as possible. In HUD mode especially, and with the usual issue of a double image due to laminated glass, it needs to be as clear as possible. What use is a status bar in HUD mode?
So I’d built a simple full-screen app with a menu accessible by the menu key. Job done. Well, it was…until I unleashed it on an unsuspecting public and more and more people started using it. Suddenly I found that if you were using a tablet then you could basically change no settings at all, except those just needing a press on the item itself (like the speed unit). Feedback poured in.
I’d decided that I could open the Menu by tapping on the screen. For me this was very natural to use as a single tap gave me all of the options available, and this worked well as an alternative to a physical menu key (or as well as), until I found that for some reason it didn’t work on tablets!
Google weren’t helping either:
Beginning with Android 3.0 (API level 11), Android-powered devices are no longer required to provide a dedicated Menu button. With this change, Android apps should migrate away from a dependence on the traditional 6-item menu panel and instead provide an action bar to present common user actions.
Now I have to provide an Action Bar, just to expose the Menu? Great. What about my full-screen cleanliness?
My eventual solution (after a lot of trial and error and changing of code) was to
keep the screen-tap menu
make the menu available to a physical menu key if present
offer the option of showing the Action Bar if desired
always show the Action Bar for devices identified as Tablets (I’m at the mercy of Android to correctly identify tablet devices here)
If all device manufacturers followed Samsung’s example and included a hardware menu key then I would have saved many hours working on this ‘simple’ issue. Or if Android always exposed a menu icon in the software navigation that would help too (I think HTC do with their later phones like the M8). Instead, for devices with no hardware keys, we lose more screen real estate by showing the software navigation and an Action Bar.
Although my solution may not be the most elegant or seamless it does at least allow the Menu to be available on all devices. I have a game installed that relies on a hardware menu key and is therefore as good as unusable on my LG G3.
