John
On Thu, Aug 30, 2018 at 10:03 AM Natal Rivadeneyra <address@hidden> wrote:
I have tried using just the ?WATCH command but there are two problems with just waiting for the GPS
1) I need millisecond accuracy. If I wait for the GPS I get the information on the second every second, but nothing in between
2) some of the third party applications we are using are very expensive processor-wise and sometimes it misses the GPS update. I have tried that before and didn't work. And even if it did, I still have problem 1 that I can't ignore
--
Natal Rivadeneyra
Manager Acquisition Systems and Software
2225 East Bayshore Road, Suite 100
Palo Alto, CA 94303
On Aug 30, 2018, 02:46 -0400, Mike Tubby <address@hidden>, wrote:
Natal,
Why are you polling at all? It is better to post a read and wait for GPSD to return some data when it has it, event driven, like select() ...
Mike
On 8/29/2018 9:56 PM, Natal Rivadeneyra wrote:Hi,
I am writing a python utility that receives data from a usb-serial port and every packet received needs to be timestamped with GPS time.
I am working with Ubuntu 16.04, GPSD 3.15 and the hardware is Garmin GPS18x LVC receiver with 1 pps.
The frequency at which the data stream is arriving to the usb-serial is ~3000 Hz.
When the utility is started I send a ?WATCH={"enable":true} command to the gpsd daemon and then I use ?POLL; every time I read a packet from the usb-serial port (~3000 times per second)
The problem I am having is that at some point the GPSD daemon throws an error and shuts down the socket:
gpsd:CLIENT: <= client(0): ?POLL;?POLL;?POLL;?POLL;?POLL;\x0a
gpsd: gpsd_json.c:130: json_tpv_dump: Assertion 'replylen > sizeof(char *)' failed.
Aborted (core dumped)
I have read in the documentation that this can happen if I don't read the buffer fast enough, but there was no mention of this happening if I poll it too fast. I have noticed that if I sleep the polling by at least 0.01 seconds then the problem goes away. Unfortunately, I don't have the luxury to sleep that long as I am receiving a new sample every 0.000333. If I sleep for 0.01 I will be losing 30 packets in a row and that is not acceptable.
I have also noticed that if I don't send the ?WATCH={"enable":true} command and just start polling right away I get the following response:
{"class":"POLL","time":"2018-08-29T01:12:52.716Z","active":0,"tpv":[],"gst":[],"sky":[]}
All I am concerned is time, I don't need tpv, gst or sky, so that would be acceptable. However, since there is an "active":0 I don't believe that the time reported is accurate. Is this an accurate assumption? I can run that same routine without the GPS receiver connected to my machine and would still get a time response.
Has anyone experienced this before? Is there a maximum polling frequency?
This is a sample code of what I am attempting to do
import socket
import json
import time
TCP_IP = '127.0.0.1'
TCP_PORT = 2947
BUFFER_SIZE = 1024
MESSAGE = '?WATCH={"enable":true}'
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((TCP_IP, TCP_PORT))
s.send(MESSAGE)
gps_data = s.recv(BUFFER_SIZE)
MESSAGE = '?POLL;'
s.send(MESSAGE)
gps_data = s.recv(BUFFER_SIZE)
while True:
#Here I would receive the serial/usb data
s.send(MESSAGE)
gps_data = s.recv(BUFFER_SIZE)
#Here I would extract the time from the received gps_data
print(len(gps_data))#This was to try and figure out the buffer size of the data that was being polled
print(gps_data) #I want to see what is it that I am receiving
#time.sleep(.01)#If I sleep the process at least .01 sec then I don't seem to get the error and the daemon doesn't shut down.
Thank you for your help and l'm looking forward to see if any of you had experienced this and if there is a workaround.
Best Regards,
--
Natal Rivadeneyra
Manager Acquisition Systems and Software
2225 East Bayshore Road, Suite 100
Palo Alto, CA 94303
John Burton, Ph.D.
MTEQ, Inc.
10440 Furnace Rd., Suite 204 Office: 540-658-2720 x1407
Lorton, VA 22079-2630 Mobile: 757-508-6208
address@hidden
Fax: 540-288-2515
Please note that the contents of this email including all attachments may be privileged or confidential in nature and are intended solely for the named recipients. If you have received this message in error, please contact the sender immediately and be aware that the use, copying, or dissemination of this information is prohibited.