MMDVMHost
MMDVMHost copied to clipboard
g4klx
GPSD data on MMDVMHost via DMRGateway
Today I have installed a GPS receiver on my DMR repeater. The GPSD daemon is operational and the data appears to be correct and GPSD is activated in MMDVM.ini. The problem is that the repeater is connected to the server via DMRGateway which overwrites the GPS information even if the [Info] section is disabled. So the GPS receiver is useless.
Roby IV3JDV
Partial modification of the previous message: GPS data is not transmitted from MMDMHost through DMRGateway. If I disable the [Info] section in DMRGateway, the position is not transmitted
I have done other tests but it seems that MMDVMHost does not connect to the GPSD Server. I did a tcpdump of port 2947 but I don't see any traffic
Looking at the gateway code, it should be relaying the position from the info and gpsd data to all of the DMR networks. You need to do a trace on the data going into the DMR Gateway and out again to see what is happening. I did test that code a long while ago and it was certainly working then.
On Sunday, 9 August 2020, 16:40:19 BST, Roby <[email protected]> wrote:
Partial modification of the previous message: GPS data is not transmitted from MMDMHost through DMRGateway. If I disable the [Info] section in DMRGateway, the position is not transmitted
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Looking at the gateway code, it should be relaying the position from the info and gpsd data to all of the DMR networks. You need to do a trace on the data going into the DMR Gateway and out again to see what is happening. I did test that code a long while ago and it was certainly working then.
I looked at the DMRGateway log... the GPS position and INFO data are displayed once as soon as MMDVMHost connects to the GW. If in the DMRGateway.ini the [INFO] section is enabled, this overwrites the one present in MMDVMHost.
I'm trying to see if the data is coming from GPSD to MMDVMHost but from the log I don't see any connection information or NMEA data. How can I be sure MMDVMHost connects to GPSD?
I did other tests, YSFGateway works perfectly with GPSD. Even if in the INFO I put the position at 0.0000, this appears corrected by GPSD. Also in the LOG we see that the GW connects to the GPSD daemon. All this does not happen with MMDVMHost
I can see no obvious error in the MMDVM Host code. Can you confirm that the host is up-to-date and compiled with the USE_GPSD line enabled within the Makefile. Secondly, is GPSD enabled in the MMDVM.ini file? Can you send me the log of your MMDVMHost starting with GPSD enabled so I can have a look at the messages that are generated, Jonathan G4KLX
On Saturday, 22 August 2020, 10:20:11 BST, Roby <[email protected]> wrote:
I did other tests, YSFGateway works perfectly with GPSD. Even if in the INFO I put the position at 0.0000, this appears corrected by GPSD. Also in the LOG we see that the GW connects to the GPSD daemon. All this does not happen with MMDVMHost
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Problem almost solved ... I apologize very much, but I had not seen that the line must be enabled in the Makefile. I recompiled and now "connected to GPSD" appears in the MMDVMHost log. I put the position in MMDVM.ini at 0.0000. If connect the repeater directly to BM after a couple of minutes the position is displayed correctly. But if I use DMRGateway the position is transmitted with wrong longitude data.
That’s odd. Can you do a network trace of the position data going into DMR Gateway and coming out. It will let me see what I’d being corrupted.
Sent from Yahoo Mail for iPhone
On Saturday, August 22, 2020, 18:36, Roby [email protected] wrote:
Problem almost solved ... I apologize very much, but I had not seen that the line must be enabled in the Makefile. I recompiled and now "connected to GPSD" appears in the MMDVMHost log. I put the position in MMDVM.ini at 0.0000. If connect the repeater directly to BM after a couple of minutes the position is displayed correctly. But if I use DMRGateway the position is transmitted with wrong longitude data.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
these are the tcpdumps of ports 2947 and 62031 from the start of the repeater until the wrong position appears on BM
The 2947 dump only shows TCP activity and no MMDVM or DMR activity. I can see the UDP RPTG transmission in the other file though. Can you try and do another capture of data going in and out of the DMR Gateway please? Also can you say which is the MMDVM side and which goes to BM. I can see no obvious problem with the code in the gateway. Jonathan G4KLX
On Saturday, 22 August 2020, 19:09:10 BST, Roby <[email protected]> wrote:
these are the tcpdumps of ports 2947 and 62031 from the start of the repeater until the wrong position appears on BM
tcpdump.zip
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
three files, ports 62031 and 62032 localhost (MMDVMHost<->DMRGateway)+ 62031 eth0 (DMRGateway <-> BM) tcpdump-v2.zip
this is the position that I see on BM
I thought the problem is solved but it isn't. Via DMRGateway the position of the repeater is wrong. Today it shows these values
I am happy to confirm that the data transmitted to the DMR Gateway to BM is identical to that sent to it by the MMDVM Host. Therefore the problem lies with BM, they are not interpreting the data correctly. They need to explain why they have added 100 degrees to your Longitude, the packet sent to BM is for 313.81697 degrees. The Latitude appears correct, the value sent being 45.63149 degrees. On Monday, 24 August 2020, 11:11:34 BST, Roby [email protected] wrote:
I thought the problem is solved but it isn't. Via DMRGateway the position of the repeater is wrong. Today it shows these values
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
I took a look at the DUMP files and saw this line: @ù-45.63149313.81697`xA_Ûx is it possible that BM uses 5 decimals and therefore interprets the sixth of the latitude as the first of the longitude?
But this only happens if I go through DMRGateway. With MMDVMHost connected directly to BM the position appears correct
You need to ask them. It correctly interpreted the same message from the host so what is different now?
Sent from Yahoo Mail for iPhone
On Monday, August 24, 2020, 12:19, Roby [email protected] wrote:
I took a look at the DUMP files and saw this line: @ù-45.63149313.81697`xA_Ûx is it possible that BM uses 5 decimals and therefore interprets the sixth of the latitude as the first of the longitude?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
I wrote a message to BM but I found that the problem also exists with MMDVMHost directly connected to BM. I believe that the problem is the number of decimals transmitted and the digit that appears in the longitude is the seventh decimal of the latitude (BM displays 6 decimal digits). I try to make more precise tests
I think we may need a new format for the RPTG message to make it more obvious.
Sent from Yahoo Mail for iPhone
On Monday, August 24, 2020, 14:25, Roby [email protected] wrote:
I wrote a message to BM but I found that the problem also exists with MMDVMHost directly connected to BM. I believe that the problem is the number of decimals transmitted and the digit that appears in the longitude is the seventh decimal of the latitude (BM displays 6 decimal digits). I try to make more precise tests
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Hi Jonathan, unfortunately I still haven't received any response from BM regarding the problem of the wrong position when using GPSD. I'm pretty sure the problem is in the decimals.
73 Roby IV3JDV
Trie use id 262999 private call , to send info gps
Enviado desde mi iPhone
El 09/14/2020, a la(s) 5:56 p. m., Roby [email protected] escribió:
Hi Jonathan, unfortunately I still haven't received any response from BM regarding the problem of the wrong position when using GPSD. I'm pretty sure the problem is in the decimals.
Hi Jonathan, BM replied ... from what I understand part of the software you wrote it and it seems that only 4 decimals are allowed in the protocol. I am attaching the table that BM published
But the strange thing is that on BM I see 6 decimals and not 4 ...
From: Roby Sent: Tuesday, September 15, 2020 6:58 PM To: g4klx/MMDVMHost Cc: Subscribed Subject: Re: [g4klx/MMDVMHost] GPSD data on MMDVMHost via DMRGateway (#627)
Hi Jonathan, BM replied ... from what I understand part of the software you wrote it and it seems that only 4 decimals are allowed in the protocol. I am attaching the table that BM published
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Last minute.... BM Team wrote "i guess the dashboard has some rounding errors"
The latest SimpleDMR branch of the DMR Gateway whould now handle it more correctly. Please note that this branch, and SimpleDMR branch of the MMDVM Host are now test beds for IPv6 work also. Jonathan On Tuesday, 15 September 2020, 20:14:46 BST, Roby [email protected] wrote:
Last minute.... BM Team wrote "i guess the dashboard has some rounding errors"
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
After a few days of testing it seems that after several hours (maybe 24) the GPS data captured via GPSD is no longer transmitted and the data written in the DMRGateway.ini is sent (in my case 0.0 0.0)
Roby
You need to see what data is being capture by gpsd first.
Sent from Yahoo Mail for iPhone
On Sunday, September 20, 2020, 16:52, Roby [email protected] wrote:
After a few days of testing it seems that after several hours (maybe 24) the GPS data captured via GPSD is no longer transmitted and the data written in the DMRGateway.ini is sent (in my case 0.0 0.0)
Roby
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
GPSD works fine and receives data from the GPS module correctly. If I use the cgps client, which connects via TCPIP as DMRgateway, I see the GPS data in real time. When DMRGateway starts it takes a couple of minutes for the data received by GPSD to be transmitted. But, after a few hours, DMRGateway no longer transmits the data from GPSD, but those declared in the DMRGateway.ini. It appears to be losing connection with GPSD.
You need to see what data is being capture by gpsd first. Sent from Yahoo Mail for iPhone On Sunday, September 20, 2020, 16:52, Roby [email protected] wrote: After a few days of testing it seems that after several hours (maybe 24) the GPS data captured via GPSD is no longer transmitted and the data written in the DMRGateway.ini is sent (in my case 0.0 0.0) Roby — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
There is no way that DMRGateway if configured to be used, will be ignored in favour of using the original data.
Which message from the DMRGateway to the Master is corrupted? I do need the network data that is being sent to be shown otherwise I cannot help you.
Thanks for your patience. When DMRGateway starts, the first position it transmits is the one written in DMRGateway.ini even if [GPSD] is enabled (I put a dummy position in the .ini file on purpose) and this appears on the BM dashboard and also on aprs.fi. After a few minutes the position read by GPS is transmitted and data change on BM and, 20 minutes later, on aprs.fi. I did not understand after how long it no longer transmits it and it is difficult for me to do a 24 hour tcpdump.