Replies: 5 comments 1 reply
-
is this the same device vk-162 |
Beta Was this translation helpful? Give feedback.
-
Yes. That is it. However, now that I have GPS working, I'm starting to think that using the TSL2591 light sensor is a better way to go. The GPS takes a minute or so to acquire a fix and there is a delay of sometimes another minute before night/day switches. I've not tried the TSL2591 but my reading about it, it's supposed to dim the display smoothly (the GPS is: day--full bright, night--full dim, no in-between). The GPS only switches at 6 pm (to night) and 8 am (to day). If you go through a tunnel, during the day it stays bright and blinds you. Parking garages have the same problem. I don't know if the TSL2591 just dims the display or does it switch day/night mode? Can anybody chime in? If the TSL2591 switches day/night mode as well as dim the display, It is probably a better choice. |
Beta Was this translation helpful? Give feedback.
-
Ah... matt2005, you're the dev man... I can ask you! Does the TSL2591 switch day/night mode? or just dim the display? |
Beta Was this translation helpful? Give feedback.
-
A GPS does have some capabilities that the TSL2591 does not. For example, since you would have lat/long you can calculate when twilight is for wherever your car currently is. Twilight changes with the time of the year, and your location on the globe. So instead of switching a 6pm and 8am, you would switch when twilight occurs. Also, from the GPS you could calculate your timezone. Currently, I've used the crankshaft command "crankshaft timezone EST" that statically sets my timezone. If I drive across time zones, it would be nice if the time zone could be calculated from the GPS. I believe that I could do this with a small python script. Thougths? |
Beta Was this translation helpful? Give feedback.
-
This is a great setup, but to piggyback off this, would there be a way to run an offline nav system, to utilize the gos for more then just time change, if so you may be able to have it detect timezones via the nav app and update the clock this way. Any thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
Folks,
I got a VK-162 USB GPS to work. These are my notes.
Why:
If your crankshaft ng (CS) unit has a real-time clock (RTC), you can turn on "Auto Day / Night" under the "CS Env" menu. This option has two times associated with it, 8 am, and 6 pm (18-12 in 24 hr notation). When you turn this on, CS will switch from day to night at these times. When CS switches from day/night it will do two things: Dim/brighten the display and tell the Android Auto (AA) to switch to day/night display. The AA day/night switch is when the map appears dark (for night mode), or light (for day mode). Generally a very nice feature.
A GPS can provide an RTC.
Hardware: I have a VK-162 is a USB-based u-blox 7 GPS, however, this should work with most USB-based GPS's. The VK-162 is very high quality for a low price, approximately $15 in the US. It has a surprisingly fast acquisition from a cold start.
How:
This assumes you can "ssh" into your CS and know about the "crankshaft" command. The following assumes you are logged into the CS.
There are two things that need to work for the VK-162 to be used as an RTC, "gpsd" and "ntp". gpsd reads the USB GPS and sends the output of the GPS to the time server daemon, ntp.
For most USB-based GPS's, gpsd just works.
A quick and dirty way of testing gpsd is to see if gpsd is started when the GPS is plugged in. A simple "ps auxww | grep gpsd" command should do. Unplugging the GPS, the "ps|grep" command should return nothing. Plug the GPS back in, try the ps|grep command and you should see gpsd running, it should look something like "/usr/sbin/gpsd -n". If you don't see it, things will get complicated, I would recommend trying to debug this issue using an ubuntu laptop or desktop rather than the CS.
Next, we need ntp to work. Skipping a lot of debugging pain and just getting to the final answer, I found that I had to change one line in the file "/etc/ntp.conf" from:
to:
The important change is the "flag1 1". It is largely undocumented, super poorly documented. Generally, ntp only wants to start if the current clock time is close to the GPS time. Since there is no battery-backed up clock on a raspberry pi, the current clock is arbitrary. This flag will allow ntp to start and change the time to the GPS time. This is the most significant change I had to make.
While we here, the parameter "time1 -1.25" is probably much too large. I would suggest leaving it out altogether. I am using "time1 0.070" after significant testing on my particular setup. However, this parameter is in milliseconds, so if -1.25 is much too large, that means the raspberry pi's clock will be 0.00125 seconds off. Not enough to argue about.
Remember that to edit this file, you need to do the "crankshaft system unlock" - edit file - "crankshaft system lock" sequence.
Lastly, the default time zone was not my time zone. To correct that I used the crankshaft command:
I'm in the US in the Eastern Standard Time (EST) time zone. Specify your time zone.
And as always, your mileage may vary.
Beta Was this translation helpful? Give feedback.
All reactions