DPRS data

[KR4PI]

I noticed today that D-Prs data is not showing up on APRS.fi. I am running a MMDVM Zum Board into DR-1X repeater. It has worked in the past but appears that sometime in April it stopped sending data and I only noticed today. I fired up my hotspot which is on the same network but with different call sign and D-PRS data immediately showed up on APRS.fi. I read here on the Facebook group that D-Prs only works when not using DMRGateway. I didn't think that was correct but I turned off DMRGateway and D-Prs still did not work. I then turned off DMR all together and D-Prs still did not work. I have reactivated DMRGateway but still no success. I have double checked the aprs port and link address even duplicated those on my hotspot but still, no data is transferred. Is there something in the config that I am missing or has there been a change? I am running Pi-Star 3.4.15 Dashboard 20180529. Thanks for all the help! Rich KR4PI

[KR4PI]

I am still experiencing difficulty with D-PRS data getting to aprs.fi. I have tied almost all of the US and Canadian aprs links without anything working. Just checked the IP address the Pi-Star DNS directs traffic to for rotate.aprs2.net and find the DNS is pointing to 110.54.43.135. with a domain name of 110-54-43-125.ppps.bbiq.jp. When I ping rotate.aprs2.net from my UDRC hotspot I am pointed to 185.43.207.219 domain name of rf.bkom.hu. Both the Pi-Star and my hotpot are on my home network. I suspect I need to flush the Pi-Star DNS, but not sure how to accomplish that.

Thanks in advance for any help.

Rich, KR4PI

[AE5PL]

rotate means there are multiple IP addresses for that fqdn. The IP addresses you are seeing are correct. What radio are you using that is sending DPRS? Have you configured it for DPRS per http://www.aprs-is.net/dprs?

I have released DStarMonitor for ircddbgateway use (that is the D-STAR gateway that is used in most hotspots including Pi-Star). I have also posted an install script for the Pi-Star. You can find out more at http://www.aprs-is.net/dprs (DStarMonitor is a sub-page). Be sure to follow the instructions to install the OpenJDK using apt-get and -disable- Pi-Star's APRS functionality (in the "Expert" sections for the the various modes). DStarMonitor is DPRS compliant. The DPRS spec (also available from that site) was incorporated in the latest D-STAR spec by the JARL.

73,

Pete AE5PL

[AE5PL]

DStarMonitor is a fully APRS and D-STAR compliant IGate. It is compliant with the D-PRS specification which has been incorporated into the latest D-STAR specification from the JARL and also provides full APRS IGate and APRS-IS server support which makes it a good neighbor to the APRS world. While ircddbgateway is an excellent D-STAR gateway implementation, APRS was added as an afterthought without consideration of what went into the DPRS specification and what it means to the APRS world. DStarMonitor fully incorporates the core javAPRSSrvr software and fully implements both APRS and DPRS specifications. Because it fully incorporates javAPRSSrvr, it is also a fully compliant APRS-IS server and IGate. It properly only reports on received D-STAR position reports so improper gating to APRS-IS of remote position reports does not occur. It properly implements the DPRS specification which reduces/eliminates callsign/position mangling and allows for gating to APRS RF by preventing streaming of D-STAR position reports to APRS.

I have a ZumSpot RPi board that is connected to my TNC-Pi GPIO pins and my Pi-Star D-STAR gateway is running DStarMonitor providing full bidirectional DPRS-compliant IGating in addition to a full APRS IGate using the TNC-Pi on a RPi 2B. This flexibility and compliance are built-in to DStarMonitor and DStarMonitor is actively maintained to be fully compliant in -both- the APRS and D-STAR worlds.

I have also noted that many DMR and Fusion installations are improperly hijacking DPRS APRS designators and trying to pass-off non-DPRS information as DPRS generated. This is a sad state of affairs when people copy what someone else has done without knowledge of adverse impact they may have on other networks. The APRS implementations in ircddbgateway and others included in Pi-Star have apparently been done without a full understanding of the APRS-IS and APRS worlds. This has tended to push back the APRS world to a situation we saw 20 years ago where everybody was implementing anything they wanted without regard to the impact to the worldwide network aspects of APRS-IS.

Hope this helps. If you are looking for a compliant, "good-neighbor" to the APRS world that is actively maintained, DStarMonitor is the way to go. If you are looking for software which is developed to "accommodate" whatever anyone perceives to be necessary without regard to the APRS world (or D-STAR world), other software is your choice. I made the changes to DStarMonitor to try to help get the non-G2/G3 community better accepted in the APRS world and to reduce the improperly gated packets (both to and from APRS-IS) that both communities would prefer to have eliminated.

73,

Pete AE5PL

[AE5PL]

Rich, are you using DMR for your reporting, I suspect so as you mention DMRGateway ? How is your BM selfcare profile and private call GPS id setup,
which are all needed for BM aprs reporting ?

"BM APRS reporting" is not DPRS and should not hijack DPRS designators in the APRS world. DPRS stands for D-STAR Position Reporting System, not Digital Position Reporting System. If the DMR and Fusion worlds want to implement APRS position reporting, they need to work -with- the APRS world in developing a well-defined translation mechanism including proper, consistent, and well-defined APRS designations and formats. This is what was done over 10 years ago with DPRS and what should be done with these modes.

73,

Pete AE5PL

[AE5PL]

I understand it is the real deal. However I have THD74, will your system work with its GPS reporting?

It will when Kenwood makes the TH-D74 D-STAR compliant. The TH-D74 is -almost- compliant and they are currently working on a fix that was presented to them by myself and others to make it fully compliant. Everything about what the D74 transmits is properly formatted but they missed the point in the most recent D-STAR spec (which is what the D74 is written to) that the GPS 20 character message field is supposed to be modifiable. I have been in talks with those associated with Kenwood to allow simple modification of the message field per the D-STAR spec and, as of my last communication with them, Kenwood is investigating a firmware release allowing modification of that field. DStarMonitor does not break the DPRS specification (which is there for a reason) to accommodate radios that are not fully compliant, which is the current case for the D74 (which I have also). Fortunately, Kenwood is a good company to work with for getting fixes in their next firmware release and we are hopeful we will see a fix to this issue soon.

So "no", DStarMonitor fully complies to the D-STAR and DPRS specifications which does not allow for potential mangled packet and non-standard packet generation. "Yes", we (myself and others) are in talks with Kenwood to make their radio compatible with all D-STAR gateway DPRS implementations so a user can know their position is being gated properly regardless of the gateway they are using.

73,

Pete AE5PL

[AE5PL]

No luck here getting this working ;

i fixed a typo in your script to install ;

wget -O /opt/DStarMonitor/DStarMonitor.zip http://www.aprs-is.net/downloads/dstar/ ... nitor4.zip

should be

wget -O /opt/DStarMonitor/DStarMonitor4.zip http://www.aprs-is.net/downloads/dstar/ ... nitor4.zip

to match the unzip filename below it.

Thanks, I will update the script (I thought I had made that change, oops).

Update, seems I resolved my issue , using sudo to test was not providing correct paths I think (guess), rather than changing to root, seems ok ;

Yes, sudo su needs to be done so everything installs as root.

However from ;

2018-08-25T04:05:55.014Z net.ae5pl.serintf.SerialIntf run
WARNING: Serial read error.
java.io.EOFException: Error reading serial port
at net.ae5pl.serintf.SerialIntf.run(SerialIntf.java:307)
at net.ae5pl.serintf.TCPIntf.overridableRun(TCPIntf.java:127)
at net.ae5pl.serintf.TCPIntf.run(TCPIntf.java:149)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Do you have the serial port hard coded to uart (ttyAMA0) ? Does it not read a mmdvm ttyACM0 etc port ?

No, DStarMonitor does not talk to the radio directly. It uses the D-RATS support in ircddbgateway which is default on. You will see that message once a day, at least, when the Pi-Star updater shuts down ircddbgateway to update everything but DStarMonitor is just warning that the connection is lost to the serial feed. If you are getting this message, it is working because it was able to find the port in the first place to establish the connection.

Nothing is "hard coded" in DStarMonitor's configuration. In the case of ircddbgateway, it is reading ircddbgateway's configuration file to set up the connections to the D-RATS ports used with non-Icom repeater radios (another connection method is used for Icom repeaters connected to RP2C which use the D-STAR communication standard between repeaters and gateways).

Hope this helps and thanks for reporting the error in the install script. Fixing that now!

73,

Pete AE5PL

PS: I leave my device connected to REF004 B if you want to talk over the air.

[AE5PL]

OK, Thankyou for all that, learning as I go here. So my THD74 transmission presently wont be recognized by DStarMonitor, because i cant enter a GPS sentence for the DPRS translation as per your online calculator, is that correct ? I wondered if the present hard coded default GPS setting on the THD74 would still make it through ?

Thankyou.

We all are continually learning (that's what makes it fun, right?)!

Kenwood made a the same mistake Icom made with the ID-880 and ID-80 a number of years ago: they made the message a fixed 20 spaces which does not allow you to configure a symbol nor does it provide for XOR checksum detection of bit errors in the callsign portion of the line. While XOR checksums are not the most reliable, we have seen in our testing many cases where there will be one or more bit errors in the callsign area but the rest of the message is untouched. That is why the DPRS translation spec was created in the first place. Icom never "fixed" the 880 or 80 because both radios supported GPS-A (DPRS) mode so the more reliable CRC encapsulation of a full APRS packet was supported and they didn't see the need to have all 880s and 80s sent back to the factory for updating (before field upgradeable radios like the 74). All of Icom's other D-STAR capable radios do allow the user to set the GPS message and the 5.0 D-STAR specification (section 6.7) shows the message as modifiable space filled to 20 characters. Our proposal to Kenwood (which I will not discuss publicly in deference to their developers) requires a minimum of alteration to their firmware and I think that is one reason they appear open to the idea of updating their firmware to be universally compatible with all D-PRS IGates.

Keep your fingers crossed that we will see a new firmware release for the 74 in the not-to-distant future to support modifying that message.

73,

Pete AE5PL

[AE5PL]

Also thankyou for the (D-Rats) serial port explanation. Is this the same as SerialPort=127.0.0.1:24580 as quoted in the manual, probably for a G3 system ? Or what is the d-rats port No please ? A netstat -tulpn on the system did not show anything obvious.

Thankyou.

No, that port is created by DStarMonitor for Icom repeaters because their handling is different from non-Icom repeaters. ircddbgateway creates a TCP port on the same port number of the UDP port for the non-Icom radio if drats is enabled. Basically, ircddbgateway provides bidirectional translation of the D-STAR DV stream portion used for serial data (originally Icom proprietary, now part of the D-STAR spec) on that TCP port. In the case of Icom repeaters where multiple repeaters are on the same UDP port, DStarMonitor does that translation so each serial stream is seen individually for each repeater. The ircddbgateway D-RATS support is what made possible easily changing DStarMonitor to support ircddbgateway regardless of the modem used while maintaining the original compatibility with Icom repeaters/controllers.

For instance, in my setup, the UDP port associated with the ZUMSpot modem is 20011 (repeaterPort1 in the ircddbgateway configuration which you can see in the Expert area of the Configuration area). DStarMonitor sees that in the configuration file, sees that drats is turned on (also in the ircddbgateway configuration file) and tries to connect to that port using TCP. If the port exists, the repeater definition is considered valid and DStarMonitior connects. We do the test first because it appears to be the only way to know for sure it is not just a dummy entry for a repeater that was there but is not anymore. You then see the EOF exception in /tmp/err.log.0 anytime that port goes away but DStarMonitor does reconnect when it comes back. This allows the Pi-Star updater to recycle ircddbgateway (and most other processes) once a day without having to restart DStarMonitor.

Hope this helps.

73,

Pete AE5PL

[AE5PL]

Does DStarMonitor send the Repeater (gateway) callsign to aprs report, was well as the RF users sending gps reports on the system?
ircddbgateway would send the Gateway callsign position reports from its /etc/ircddbgateway lat | long config, Does DStarMonitor also do this ?

Yes, DStarMonitor generates 2 different APRS packets for each repeater (remember, ircddbgateway's original implementation was based on what DStarMonitor was already doing many years ago). The primary thing that DStarMonitor generates is an IGate posit with a D overlay to indicate a DPRS IGate. All RF received posits (either GPS/NMEA or GPS-A/DPRS) are also shown as gated to APRS-IS by that repeater (callsign-ID).

The second is an APRS Item using the 8 character D-STAR callsign field as the Item name. An Item is an APRS Object without the timestamp. Since the timestamp was used to indicate last-activity on the repeater and since that integration is not available for non-Icom repeaters using ircddbgateway, the timestamp was done away with. This also helps differentiate type of repeater in use for people doing a lookup.

Finally, DStarMonitor was written with the understanding that D-STAR DV is a streaming protocol and people do not want to see extraneous transmissions from the repeater. While those packets are generated to APRS-IS, they are not generated to RF thereby keeping the frequency clear for voice communications. This was also implemented with the original ircddbgateway functionality so D-STAR RF users would not be annoyed by repeated repeater key-ups with no audio.

Hope this helps.

73,

Pete AE5PL