I have a GPS receiver, which I want to use with gpsd on Linux. It has a 3-state switch: off-on-log. On "log" mode, it's sending $GPGGA, $GPGSA, $GPGSV, $GPRMC, and $GPGGA NMEA messages, once a sec. When I toss the switch into "on" mode, it sends these messages for a while, then stops sending messages.
What is the NMEA query, which triggers sending of similar 1-sec messages? I need only position, anyway.
Is it possible that old devices does not support such NMEA query or queries at all? It's a pretty old device, with Sirf-II chip.
I can attach to the GPS with miniterm, so I can enter queries by keyboard. $PXEMQTF*6E (Quick Test) did not work.
When I toss the switch into "on" mode, it sends these messages for a while, then stops.
It shouldn't be stopping. Something is probably broken. Normally, no messages are needed to wake up the unit.
Is it possible that old devices does not support such NMEA query or queries at all?
I've never seen one that doesn't support NMEA. NMEA 0183 has been around since 1983, predating GPS itself.
SiRF (at least SiRFstarIII and later) supports its own binary protocol as well, but they also support NMEA.
Related
I've got a sim connected to my microcontroller. The rst, i/o, and clck pins are wired correctly. There is a hardware UART on my board, but since it is full-duplex and not half, I've jumperd RX/TX together.
So far, I toggle RST according to ISO-7816, and my UART buffer fills up with the ATR the sim card responds with. Once I've received the ATR, I change the UART to TX mode and send it a PPS. After sending, I change the UART back to RX only mode. It follows the correct format as stated in ISO-7816, but I do not receive the confirmation bytes from the sim. The confirmation is supposed to be a repeat of the settings I sent.
I suppose your problem is of the same origin as I had with gsm modems.
Sending a command you get an acknowledgement from the device, then send the next command, get ack, etc, etc. Soon or later the device hangs up.
The key is the interpretation of the acknowledgement.
You may think the acknowledgement means the command is accepted AND executed. However - at least at ALL gsm modems I know - it means no more but the command was accepted and INTERPRETED - but not executed. In case of time consuming commands you send your next command during previous command is being executed. You do it because you may think acknowledgement means the command is done - but it is not true.
The device may or may not buffering cumulative commands, but soon or later the device runs out of resources and hangs up.
I have no experience with device you use but the phenomena seems to be the same.
While I'm not a protocol expert, the most likely cause seems to me, that you send PPS too early- "after sending" can be easily too early on modern microcontrollers. ISO 7816-3 states, that the guard time applies as usual and the waiting time is 9600 etu's.
Sending PPS too early means, that the card does not yet listen, which perfectly explains receiving no response at all. Wrong format would cause an error block, which should also be visible on the scope, which supports my assumption.
I am creating a server on a ST Cortex M3 device. I am using the lwip API and FreeRTOS. All is working, but the response time is way off. I am currently using lwip 1.3.2 and FreeRTOS 7.3.
A single client connects to the server and must have some time-critical data sent frequently. These packets are on the order of 6 or so bytes. Other times, I am sending upwards of 20K.
The problem I am having is that these smaller packets seem to be taking forever to be sent. I assume this is because lwip is waiting for more data to be enqueued to make more efficient transmissions. I cannot wait around for 2 or 3 seconds for the data to be sent; the client is expecting the data nominally in a few micro-seconds or milli-seconds.
I have tried using lwip_send and lwip_write. (I understand that one is the same as the other with a flag passed at the end. Just had to try...) I have tried setting TCP_NODELAY on the socket to no avail. I tried to set SO_SNDLOWAT to '1', but this always returned -1, so I do not think it is supported.
I do not want to redo all of my code using TCP RAW. Is there a way to invoke the tcp_output() function outside of TCP RAW mode? Is there any way to speed things up or is this just how slow lwip TCP with small packets is?
Any and all suggestions are welcome. Thanks.
--EDIT--
I would also like to add that once I am ready to transmit, I make sure that my TX task in FreeRTOS is at the highest priority. There are no other tasks running up to the point at which I call lwip_send/write.
I'm fairly experienced with bare metal lwIP on xilinx and lwip does not wait to send things out. It will pump packets out as fast as your interrupts are acknowledged based on the ethernet hardware. I've been using UDP only. What is coming to mind though, is your problem might be on the receive end. If you are doing TCP, maybe those small packets are coming out late because you are having receive issues. What you need to do is find in the code the lowest level point at which ethernet is transmit, put a general purpose output toggle on that. Then also put a general purpose output toggle on when a ethernet packet is received. Look at the signals on a scope. If it confirms your hypothesis, then move the output toggles around to narrow down the issue. Wash, rinse and repeat until you are down to where the issue its. It's crude and time consuming, but oftentimes this brute force approach solves many "impossible" embedded software problems, due to pure determination. Good luck!
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.
We have developed an application on Windows.net mobile framework and it is used on a Windows 6.5 Smartphone. for our location based application. Our application is real time and tracks our employees. We are finding that the device loses its GPS signal.
Has anyone managed to restart the GPS receiver so that it starts giving the GPS signal again. I would be ever so gratefull if someone can help. We are using GeoFramework2.0 to deliver the geographic information that you need.
Regards
Sandy
The GPS is "shut down" when no application is using it. Just close your handles and re-open them.
If the GPS on your device is part of the WWAN radio (i.e. cellular phone) it may get put in to a low power state rather than being actually shut off. In that case, you can try restarting the radio.
If that doesn't work, some GPS's will allow you to send proprietary commands to them to force a reset or clear the memory. These commands are not standard and will differ significantly by manufacturer. If you have a SiRF GPS, take a look at the SiRF Binary Protocol Reference.
im trying to read the current position of GPS Device...using N95 from Nokia.
I read tht i will need my device to return the NMEA lines to the serialport and then i will parse/split it to get things I want but all along I dont know what to write to the serialport to make device return the NMEA ?
Like There are other commands of AT for messaging etc...Is there any specific command to send to serialport to get NMEA ???
I found this site site which seems to guide you through everything you need to do.
I am not sure how it works in the N95, but in my HTC phone you cannot send commands to the GPS device to have it behave in a certain manner. Once I am connected to the serial port that the GPS device uses I can read a stream of data coming from it, which happens to be NMEA data. There is no way that I have found to send commands to the device to tell it how to behave.
I haven't used that specific GPS device before, but for mine, I just have to open the port and I start receiving the NMEA data immediately.
I have an N82, and as far as I know it doesn't speak NMEA directly. I use a script from this page - specifically one the titled "# Turn your S60 phone with an internal GPS (eg your N95) into a Bluetooth GPS" - to get NMEA strings.
Ahh oki so I need to run some script.Oki I think i should buy a specific GPS Device for it.
Which device will do my job in cheapest manner ?
I've never worked specifically with the N95, but most GPS devices will just start spitting out NMEA as soon as they're powered up, regardless of whether or not they have a lock. I don't know how the N95 is designed, but I'll bet it probably wasn't designed to give you access to the raw NMEA data from the GPS. You'll probably need some pretty fancy trickery to get it to do that.
If you don't need to use the N95, you might find it easier to just get a GPS module and use that instead. I've always purchased mine from SparkFun. They have some good evaluation boards boards and tutorials to help you get started.
A great way of doing this in Java ME is to use JSR 179: the Location API. Your app needs to create an implementation of LocationListener, then set it on the default LocationProvider. When your listener's locationUpdated method gets called, call:
location.getExtraInfo("application/X-jsr179-location-nmea");
This will provide access to the NMEA sentences.
You can send this over a serial port by using the Java ME commports mechanism (use:
System.getProperty("microedition.commports");
as described here).
Hope this helps,
funkybro