MMDVMHost
MMDVMHost copied to clipboard
Report DMR only repeater information to APRS.
Hi Gang
I'm not sure if I am missing someting.
I can set the location in MMDVM.ini and this is reported to the Brandmeister Server I am connecting to and shown on the Brandmeister dashboard.
When I also use YSFGateway and ircddbgateway those submit the repeater position to APRS IS with some information about the frequencies. So while I was on vacation, that was cool, I could look at aprsdirect.com and could have found some close repeater offering C4FM or D*Star. But what about DMR only repeater?
DMR only repeater do not show up there. At least I found no way to make my DMR only dual hat hotspot show up on APRS also MMDVM.ini does not incluse an [aprs] section.
Also if I enable GPS position reporting on my DMR Handheld, my position is shown on the aprs map, and the via indicates it was received via my hotspot, but as this is missing, the nice coverage map feature of aprsdirect.com also cannot show the reach of my hotspot.
Would it be the task of the brandmeister servers to push objects to APRS or is this something which could be included in MMDVMHost?
73 -Benoit- HB9EUE
All DMR APRS reporting is done via BM, not from the MMDVM. The host reports the host position to BM using the data from the ini file (or a GPS receiver) but does not send it directly.
But is this a choice or a necessity? Why can't APRS DMR data be transmitted directly to the server like YSFGateway or ircDDGateway do? A repeater is not necessarily connected to BM
Roby IV3JDV
It is choice. There is no standard for DMR GPS data, and to add it would have taken a long time. If someone wants to add it......
Sent from Yahoo Mail for iPhone
On Friday, August 7, 2020, 07:29, Roby [email protected] wrote:
But is this a choice or a necessity? Why can't APRS DMR data be transmitted directly to the server like YSFGateway or ircDDGateway do? A repeater is not necessarily connected to BM
Roby IV3JDV
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
I think we talk about two different things:
1: Reporting Positions of Radios broadcasting their GPS Data to APRS. Sure, this is something which has to be done by Brandmeister, as they get and decode those packets.
2: (this is what I was talking about): Reporting the position of the repeater itself to APRS, with Information about it's frequencies and CC so it can be found on the map. This position is configured in MMDMVHost.ini (and can also be updated by gpds now I believe). This is something which MMDVMhost could be sending to APRS as there is no need to decode a packet from a radio.
Yes, I have found some PHP script, which I suppose is intended to be run on the BM Master Server to export this data to APRS. But it looks like the Server Admins do not run this script. My hotspots do now show up on the map. Nice features like aprsdirect.com coverage map is not available this way.
73 Benoit HB9EUE
yes Benoit, you are right. I also meant point 2
I know that the MMDVM sends details of the repeaters location, CC and other information to all of the DMR networks. You need initially to ask BM why it isn't being displayed. I could do it myself but I thought that they were handling it. Please do so, and let me know what they say. For it to work properly the transmitted position must include the repeater in the path otherwise the map won't show the RF connection.
But wouldn't it be possible to insert the APRS code that is present in YSFGateway and NXDNGateway into the MMDVMHost to directly transmit the position of the repeater to the APRS server without going through BM?
It is easy, but I always expected BM to provide that information to APRS.fi. Please ask them why it isn’t being sent out. Without being able to add the repeater callsign to the APRS path, it won’t display properly.
Sent from Yahoo Mail for iPhone
On Friday, August 7, 2020, 18:19, Roby [email protected] wrote:
But wouldn't it be possible to insert the APRS code that is present in YSFGateway and NXDNGateway into the MMDVMHost to directly transmit the position of the repeater to the APRS server without going through BM?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Jonathan, many thanks for the time you dedicate to us. But if I have a network of repeaters connected, for example, to a HBLink server, it would be nice to be able to transmit the position of the repeaters on APRS.fi. Then be able to decide whether to send the data via MMDVM or directly to the APRS Server
I had a look on how positions from handhelds are sent to APRS IS via BM. I updated my callsign to HB9EUE-3 in the MMDVMHost .ini file to be able to clearly identify it.
HB9EUE-8>APBM1D via HB9EUE-3,DMR*,qAR,HB9EUE-3
Well, so from my understanding, this clearly states the packet from HB9EUE-8 (Hytera Handheld) was received by the iGate HB9EUE-3 which is MMDVMhost.
So if MMDVMHost would push the position of HB9EUE-3 to APRS IS it would show up correctly, it would show which clients send packets to it, and aprsdirect.com could create coverage maps.
Only issue I found, is that if you don't put your callsign without suffix in MMDVMHost's ini file, it does now show up under 'hotspots' on your BM Dashboard. But as you can still access it via entering the correct URI, I suppose that is just something the BM web devs didn't consider.
So, IMHO, providing a way to publish your repeater / hotspot to APRS IS as YSFGateway does, would be beneficial to all.
73 HB9EUE
There is no DMR standard for transmitting GPS data. Therefore any development would have to be able to handle (at least); Motorola, Hytera, Kenwood, and Chinese handhelds, and a few others. I do not have all of these radio types with GPS and have no intention of buying them. I think BM do a very good job with the data. If you would like the DMR Gateway to handle the DMR GPS data then it would be a good idea to find someone to develop it. I am too busy with other things to do so. Jonathan G4KLX/HB9DRD
On Saturday, 22 August 2020, 14:31:09 BST, Benoît Panizzon <[email protected]> wrote:
I had a look on how positions from handhelds are sent to APRS IS via BM. I updated my callsign to HB9EUE-3 in the MMDVMHost .ini file to be able to clearly identify it.
HB9EUE-8>APBM1D via HB9EUE-3,DMR*,qAR,HB9EUE-3
Well, so from my understanding, this clearly states the packet from HB9EUE-8 (Hytera Handheld) was received by the iGate HB9EUE-3 which is MMDVMhost.
So if MMDVMHost would push the position of HB9EUE-3 to APRS IS it would show up correctly, it would show which clients send packets to it, and aprsdirect.com could create coverage maps.
Only issue I found, is that if you don't put your callsign without suffix in MMDVMHost's ini file, it does now show up under 'hotspots' on your BM Dashboard. But as you can still access it via entering the correct URI, I suppose that is just something the BM web devs didn't consider.
So, IMHO, providing a way to publish your repeater / hotspot to APRS IS as YSFGateway does, would be beneficial to all.
73 HB9EUE
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Hi Jonathan
I fear you are still misunderstanding my input. It's NOT about transmitting position of DMR Handhelds to APRS IS, this is already done by Brandmeister. That works, they decode the packets from the various handheld variants. As you see im my example where my Hytera Handheld (HB9EUE-8) sent it's position to APRS.
It did so via HB9EUE-3 which is my MMDMVMHost Repeater.
HB9EUE-3 cannot be found on APRS. And this is the Callsign configured in MMDVMHost for my repeater.
What I was suggesting, is adding a way to optionally publish the coordinates of the repeater, those which are configured in the ini file of MMDVMHost, to APRS. Those are in a defined format. This already works in YSFGateway etc.
That would make it possible for aprsdirect.com to plot coverage maps This would look nice, when aprs.fi or aprsdirect.com can display the path the packet took. This would make it possible for repeaters to show up on the map.
73 Benoit / HB9EUE
Hi Benoit As part of my changes to the APRS protocol, I've moved the GPSD handling into DMR Gateway and other changes. I have also added the ability for the DMR Gateway to report its position to APRS-IS in the same way as the YSF Gateway and others. If you get the SImpleDMR version of the DMR Gateway, and the SimpleDMR version of the MMDVM Host and try those, after making note of the configuration changes, it may do what you want it to do. Jonathan G4KLX
On Saturday, 22 August 2020, 16:32:28 BST, Benoît Panizzon <[email protected]> wrote:
Hi Jonathan
I fear you are still misunderstanding my input. It's NOT about transmitting position of DMR Handhelds to APRS IS, this is already done by Brandmeister. That works, they decode the packets from the various handheld variants. As you see im my example where my Hytera Handheld (HB9EUE-8) sent it's position to APRS.
It did so via HB9EUE-3 which is my MMDMVMHost Repeater.
HB9EUE-3 cannot be found on APRS. And this is the Callsign configured in MMDVMHost for my repeater.
What I was suggesting, is adding a way to optionally publish the coordinates of the repeater, those which are configured in the ini file of MMDVMHost, to APRS. Those are in a defined format. This already works in YSFGateway etc.
That would make it possible for aprsdirect.com to plot coverage maps This would look nice, when aprs.fi or aprsdirect.com can display the path the packet took. This would make it possible for repeaters to show up on the map.
73 Benoit / HB9EUE
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Hi Jonathan, I also tried this version and unfortunately the transmission to APRS.FI does not work. From the APRSGateway log I don't see any TX from DMRGateway. I spoke to BM about the incorrect display issue. I'm waiting for a reply
Good news, just wait .. DMRGateway also transmits the position to APRS.FI. Great job Jonathan
Which GPS device do you use?
https://www.amazon.it/gp/product/B07LBWF1P7/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
I've ordered one, same model, different seller. Did you need to do anything with gpsd to make it work. I have a u-blox M8 and could not get it to work with gpsd, although it works with the Windows software perfectly.
On Friday, 28 August 2020, 17:09:16 BST, Roby <[email protected]> wrote:
https://www.amazon.it/gp/product/B07LBWF1P7/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Nothing. Just I configure /etc/default/gpsd with the used ttyACM USB port and I used the "-G" option
Hi Jonathan
Thank you for your excellent work. But I don't manage to get them to talk to each other.
I cloned the repositories DMRGateway and MMDVMHost and switched both to the SimpleDMR branch, compiled.
MMDVMHost I: 2020-08-30 07:18:39.494 DMR Network Parameters I: 2020-08-30 07:18:39.494 Address: 127.0.0.1 I: 2020-08-30 07:18:39.495 Port: 62031 I: 2020-08-30 07:18:39.495 Local: random I: 2020-08-30 07:18:39.495 Jitter: 360ms I: 2020-08-30 07:18:39.495 Slot 1: disabled I: 2020-08-30 07:18:39.495 Slot 2: enabled I: 2020-08-30 07:18:39.495 Mode Hang: 300s
DMRGateway I: 2020-08-30 07:18:05.272 MMDVM Network Parameters I: 2020-08-30 07:18:05.272 Rpt Address: 127.0.0.1 I: 2020-08-30 07:18:05.272 Rpt Port: 62032 I: 2020-08-30 07:18:05.272 Local Address: 127.0.0.1 I: 2020-08-30 07:18:05.272 Local Port: 62031 M: 2020-08-30 07:18:05.273 MMDVM Network, Opening M: 2020-08-30 07:18:05.273 Waiting for MMDVM to connect..... M: 2020-08-30 07:18:09.345 Packet received from an invalid source, 0100007F != 0100007F and/or 62032 != 49786 M: 2020-08-30 07:18:19.358 Packet received from an invalid source, 0100007F != 0100007F and/or 62032 != 49786 M: 2020-08-30 07:18:53.434 Packet received from an invalid source, 0100007F != 0100007F and/or 62032 != 60466 M: 2020-08-30 07:19:03.448 Packet received from an invalid source, 0100007F != 0100007F and/or 62032 != 60466 M: 2020-08-30 07:19:13.449 Packet received from an invalid source, 0100007F != 0100007F and/or 62032 != 60466
What did I miss?