As seen in:
http://aprs.gids.nl/nmea/#gga
The first part of the GPGGA sentence , is UTC time. for example:
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
The UTC time is: 12:35:19
My GPS device output the sentence:
GPGGA,000019.032,,,,,0,00,,,M,0.0,M,,0000*5F
As I see it, this is a standard - these sentences have a certain structure.
Or am I wrong?
It would appear that your GPS does not have a fix yet. If it doesn't have information from satellites, then it doesn't know what time it is.
The time you see is likely indicating that your GPS has been on for 19 seconds, or that it thinks it is 00:00:19 based on an internal clock that was running since the time was last received.
Looks like GPS is not in sync with satellite signal, so it is showing time from internal clock.
#kaushik, did you connected the antenna. If you connected pls check whether your gps has active receiver or passive receiver.
Related
I'm trying to identify bus stops using GPS dataset including those attributes:
Bus Number
Current Bus Latitude
Current Bus Longitude
Current Time Recorded
I grouped data by bus_no and date and I did calculation on the data to get distance, duration, speed, and each stop occurred with its duration until a move happen. Now I want to identify bus stop from these set of stops occurred some of these stops occurred because of a traffic or because it's a bus stop and I want to identify this so is it a way to do it ?
I tried to read papers on this problem but I didn't find any thing that like this. most of papers already have stops determined.
So is there anyone can give me an advice for how I can solve this problem?
The main difference between a bus stop and a traffic stop in your situation is the duration of the stop. Bus stops duration would be consistent and short, rather than long and inconsistent like a traffic stop, hence I would advise you to create small bins of duration and plot a histogram. Ideally, the highest bin would be your bus stop duration, then you can map the duration bin back to the stops.
I have a GPS circuit board from china. The only information I can find on this thing is :"amoj GPS 04C www.amoj.com"
It has a serial (DB9) connection and I would like to determine how to putty into it or something.
How can I determine what the port settings that are required to access this?
Pictures below:
Photos in Dropbox
The Jupiter TU60 serial interface is 9600 8N1 by default. The only sentence it will output automatically is the flash checksum message about a second after power up. Google the datasheet for the device and it will let you know about this.
To have it output the position and other information, you must command it to do so. There is a default set of commands that are active after power up. They begin with ## and are from the protocol used by Motorola. Refer to the M12+ Users Guide and Supplement (available online) for information on how to use these commands. I have been able to enter them from Realterm. The only tricky part is calculating the checksum. You can use most hex calculators to do that.
According to the datasheet, the unit goes into survey mode automatically and after about 24 hours goes into position hold. The 1PPS and 10KHz signals are valid to less than a microsecond after a few minutes after power up and to 50nS after a day. I have compared this to another standard I have to verify this. You can use the ##Ea command to get the status of the unit and the M12+ Manual will tell you how to decode it.
Look for $GP... messages at 4800 and 9600BPS as yegorich suggest. Common NMEA messages output by GPS devices are $GPGGA, $GPVTG, $GPRMC.. If you find that data coming out, use Google to look up NMEA 0183 sentence structure and you will have what you need...
I have the same board with the Navman jupiter T Tu60 GPS 1pps 10khz GPS Module on it. I just received my sma antenna and have hooked it up. I am using 12.6V power to the centre pin.
It outputs 1pps on the led with no signal, so that is not to be trusted. Mine is labeled 1pps and 10khz underneath the pcb but these are actually swapped! I put the 10KHz output on my dso and get a 10KHz square wave 50% duty cycle signal but there is ringing on the waveform rise so I have to set the trigger level to 0.8v to get the dso to register the 10KHz frequency. I suspect this may be because the output expects a load and is not seeing one. Now, was I using ac or dc coupling?
I too am getting nothing on the serial. I tried 9600, 4800 using putty on com1 (I have a nice old motherboard) and then tried reversing rx and tx but no luck. As of now I am checking out the serial signals with the dso to see if I can work out what is happenning. I suspect that these boards are rubbish, and useful as power supplies only.
It reads 10.0000 on my hp 5328a counter and sometimes reads 9.9999. It would be nice to be able to talk to the gps to see whether it has satellite lock.
Please let me know how you get on and if you find out any further info.
Brett VK6EZ.
I'm writing a simple virtual serial port device to report an older serial port. By this point I'm able to enumerate the device and send/receive characters.
After a varying number of bulk-out transmissions from the host to the device the endpoint appears to give up and stop transferring data. On the PC side I receive a write error, and judging from a USBlyzer trace the music stops on a stall (USBD_STATUS_STALL_PID). However my code never intentionally issues a STALL condition on that endpoint and the status flag for having generated one never gets set though.
Given the short amount of time elapsed (<300 µs) between issuing the request and the STALL it would appear to be an invalid response of some sort, and not a time-out. On the device side the output endpoint is ready to go, with data in the buffer and proper DATA0/1 synchronization, but nothing further ever happens.
Note that the device appears to work fine even for long periods of time until I start sending "large" quantities of data. As near as I can tell the device enumeration/configuration also appears to complete successfully. Oh, and the bulk-in endpoint continues to work just fine after this.
For the record I'm using the standard Windows usbser.sys driver and an XMega128A4U µP. I'm also seeing the same behaviour across multiple Windows Vista and 7 machines.
Any ideas what I'm doing wrong or what further tests I might run to narrow things down?
USBlyzer log,
USB CDC stack,
test project
For the record this eventually turned out to be an oscillator problem. (Apparently the FLL's reference is always 1,024 Hz even when the 1,000 Hz USB frames are chosen. The slight clock error meant that a packet occasionally got rejected if it happened to contain one too many 1-bits in a row.)
I guess the moral of the story is to check the basics before assuming you've got a problem with the higher-level protocol. Also in retrospect a hardware USB analyzer would have been a worthwhile investment, the software alternatives mostly seems to spit out a generic error code or nothing at all when something goes awry.
Stalling the out-endpoint may happen on an overflow of the output buffer on the host side. Are you sure that the device does fetch the data it receives via out-endpoint - and if so does it fetch the data at least as fast as data is sent to the device?
Note that the device appears to work fine even for long periods of
time until I start sending "large" quantities of data.
This seems to be a hint for an overflow of the output-buffer.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How can I locally detect iPhone clock advancement by a user between app runs?
Is there a way to determine the actual time and date in iOS (not the time of the device)
Is there a clock in iOS that can be used that cannot be changed by the user
Brief
I am working with an auto-renewable subscription-based app. When the app receives the latest receipt from Apple, it stores the expires_date_ms key in NSUserDefaults. Thirty days after that date, the app checks with Apple to see if the subscription is still active. The app can be considered an offline app, but it must connect to the internet once every 30 days in order to check the subscription status. This time comparison will be used to tell the user he/she must connect.
Problem
I am using the code below to compare the current time with the expires_date_ms:
NSTimeInterval expDateMS = [[productInfo objectForKey:#"expires_date_ms"] doubleValue];
NSTimeInterval currentDateMS = ([[NSDate date] timeIntervalSince1970] * 1000);
if (currentDateMS > expDateMS)
subExpired = YES;
This is fine and works well, but from what I can tell there's a loophole that can be exploited - if the user sets the device's clock back a hour/month/decade, the time comparison will become unreliable because [NSDate date] uses the device's current time (please correct me if I'm wrong).
Question
Is there any way of retrieving a device-independent time in milliseconds? One that can be accurately and reliably measured with no regards to the device clock?
While Kevin and H2CO3 are completely correct, there are other solutions for the purposes of checking a subscription (which I would hope does not need millisecond accuracy....)
First watch UIApplicationSignificantTimeChangeNotification so that you get notifications of when the time changes suddenly. This will even be delivered to you if you were suspended (though I don't believe you will receive it if you were terminated). This gets called when there is a carrier time update, and I believe it is called when there is manual time update (check). It also is called at local midnight and at DST changes. The point is that it's called pretty often when the time suddenly changes.
Keep track of what time it was when you go into the background. Keep track of what time it is when you come back into the foreground. If time moves radically backwards (more than a day or two), kindly suggest that you would like access to the network to check things. Whenever you check-in with your server, it should tell you what time it thinks it is. You can use that to synchronize the system.
You can similarly keep track of your actual runtime. If it gets wildly out of sync with apparent runtime, then again, request access to the network to sync things up.
I'm certain that attackers would be able to sneak 35 days or whatever out of this system rather than 30, but anyone willing to work that hard will just crack your software and take the check out entirely. The focus here is the uncommitted attacker who is just messing with their clock. And that you can catch pretty well.
You should test this carefully, and be very hesitant to accuse the user of anything. Just connecting to your server should always be enough to get a legitimate user working again.
You need to connect to/retrieve information from a reliable, official time server and use that time data in your app. For example, here's a world time server with an easy-to use API
Here are three options I can think of:
clock_gettime(CLOCK_MONOTONIC) gets the current system uptime. This is relatively unreliable because if the user reboots, this is reset. You could save the last value used and at launch use the last saved value as an offset, but the problem with this is that the time that the device was shut off for won't be calculated.
mach_absolute_time() counts the number of CPU ticks since the last reboot. It can be fetched easily through CACurrentMediaTime. Note that this can be reset simply by rebooting the device, so if changing the time is very important, I'm not so sure if you would go this way.
Network Time Protocol (NTP) is a networking protocol for synchronizing the clocks of computer systems. In practice, all NTP is is querying a time server. An iOS library for NTP can be found here.
So the first two methods do not require connectivity, while the third does. However, the third method is the only foolproof one.
There is no such thing as a non-mutable device clock that persists across reboots. The only way to get a trustworthy time is to contact a remote server that you trust and ask what its time is.
I am creating a BREW app that requests the user's position.
If the phone cannot acquire the position, I would like to display an error.
How long should I wait for my callback to be called before I determine that the phone is not likely to get a GPS fix?
When a cold start is required, the receiver has to download a full set of Ephemeris data, which is broadcast from the GPS satellite over a 30 second cycle and re-transmitted every 30 seconds.
So I would say that 60-90 seconds (two or three Ephemeris cycles) would be a suitable time to wait before declaring failure.
http://www.navigadget.com/index.php/gps-knowledge/ttff-time-to-first-fix
Note that if a device requires an almanac download, the startup time can be much longer (on the order of 12.5 to 15 minutes). This is referred to as a Factory TTFF (Time to First Fix).
I might go with an increment (say 20 or 30 seconds) between notifying the user that you have failed to establish a link, and give them the option to stop trying. Keep at it until they stop you, or a set number of iterations have passes (say 5 - 10 iterations).
45-90 seconds.
For more information, see the GPS Time To First Fix article at Wikipedia.
But you can never know when the user actually has view to the satellites or not, maybe they are still inside when they start your program, so the approach suggested by Matthew Vines is much better than a constant delay.
Cellphone-specifically, I've had a Motorola phone that had a GPS receiver, but was horrendously bad at it - it could take it around 5 minutes to get a fix where my standalone Bluetooth receiver would manage in less than a minute.
Why are you declaring failure after a fixed timeout anyway? Why not, after a reasonable time has passed (say, a minute), display a message to the tune of "GPS fix still not available; but I'm still trying" with a possibility to cancel at any time if the user is fed up? What do you expect the user to do with the failure message you're proposing to give him?