[chirp_devel] issue #967 - add aprs beacon and message parsing
issue #967 - add aprs beacon and message parsing
The FT1DR stores the APRS messages and beacons in the clone. This patch displays those messages in the settings tab.
diff -r c3dacbee3ecf -r 3e008f702ad9 chirp/ft1d.py --- a/chirp/ft1d.py Sat Dec 27 23:16:48 2014 -0700 +++ b/chirp/ft1d.py Sun Dec 28 10:41:55 2014 -0700 @@ -16,6 +16,7 @@
import os import re +import string
from chirp import chirp_common, yaesu_clone, directory from chirp import bitwise @@ -317,19 +318,19 @@
#seekto 0x%04X; struct { - u8 dst_callsign[6]; - u8 dst_callsign_ssid; - u8 src_callsign[6]; - u8 src_callsign_ssid; - u8 path_and_body[%d]; + char dst_callsign[9]; + char path[30]; + u16 flags; + u8 seperator; + char body[%d]; } aprs_beacon_pkt[%d];
#seekto 0x137c4; struct { - u8 unknown0; - u8 dst_callsign[6]; + u8 flag; + char dst_callsign[6]; u8 dst_callsign_ssid; - u8 path_and_body[66]; + char path_and_body[66]; u8 unknown[70]; } aprs_message_pkt[60];
@@ -515,7 +516,7 @@ _mem_params = (0xFECA, # APRS beacon metadata address. 60, # Number of beacons stored. 0x1064A, # APRS beacon content address. - 162, # Length of beacon data stored. + 134, # Length of beacon data stored. 60) # Number of beacons stored. _has_vibrate = False _has_af_dual = True @@ -944,6 +945,54 @@
return menu
+ def _get_aprs_msgs(self): + menu = RadioSettingGroup("aprs_msg", "APRS Messages") + aprs_msg = self._memobj.aprs_message_pkt + + for index in range( 0, 60 ): + if aprs_msg[index].flag != 255 : + val = RadioSettingValueString(0, 9, + str(aprs_msg[index].dst_callsign).rstrip("\xFF") + "-%d" % aprs_msg[index].dst_callsign_ssid ) + rs = RadioSetting("aprs_msg.dst_callsign%d" % index, "Dst Callsign %d" % index, val) + menu.append(rs) + + val = RadioSettingValueString(0, 66, + str(aprs_msg[index].path_and_body).rstrip("\xFF")) + rs = RadioSetting("aprs_msg.path_and_body%d" % index, "Body", val) + menu.append(rs) + + return menu + + def _get_aprs_beacons(self): + menu = RadioSettingGroup("aprs_beacons", "APRS Beacons") + aprs_beacon = self._memobj.aprs_beacon_pkt + + for index in range( 0, 60 ): + # There is probably a more pythonesque way to do this + if int( aprs_beacon[index].dst_callsign[0] ) != 255 : + #print "DST callsign %s %d %s" % ( aprs_beacon[index].dst_callsign, aprs_beacon[index].dst_callsign[0], list( str( aprs_beacon[index].dst_callsign ))) + val = RadioSettingValueString(0, 9, + str(aprs_beacon[index].dst_callsign).rstrip("\xFF") ) + rs = RadioSetting("aprs_beacon.dst_callsign%d" % index, "DST Callsign %d" % index, val) + menu.append(rs) + + path = str( aprs_beacon[index].path ).replace( "\x00", " " ) + path = ''.join(c for c in path if c in string.printable).strip() + path = str( path ).replace( "\xE0", "*" ) + #print "path %s %s" % ( path, list(path) ) + val = RadioSettingValueString(0, 32, path) + rs = RadioSetting("aprs_beacon.path%d" % index, "Digipath", val) + menu.append(rs) + + body = str( aprs_beacon[index].body ).rstrip("\xFF") + checksum = body[-2:] + body = ''.join(s for s in body[:-2] if s in string.printable).replace( "\x0d", " " ) + val = RadioSettingValueString(0, 134, body.strip()) + rs = RadioSetting("aprs_beacon.body%d" % index, "Body", val) + menu.append(rs) + + return menu + def _get_aprs_rx_settings(self): menu = RadioSettingGroup("aprs_rx", "APRS Receive") aprs = self._memobj.aprs @@ -1378,6 +1427,8 @@ self._get_aprs_rx_settings(), self._get_aprs_tx_settings(), self._get_aprs_smartbeacon(), + self._get_aprs_msgs(), + self._get_aprs_beacons(), self._get_dtmf_settings(), self._get_misc_settings(), self._get_scan_settings())
Thanks Angus I have a pretty new FT1DE, will try your patches later today.
May I help you in any way with this new model? Do you want me to test something?
73 de IZ3GME Marco
On 28/12/2014 18:51, Angus Ainslie wrote:
issue #967 - add aprs beacon and message parsing
The FT1DR stores the APRS messages and beacons in the clone. This patch displays those messages in the settings tab.
diff -r c3dacbee3ecf -r 3e008f702ad9 chirp/ft1d.py --- a/chirp/ft1d.py Sat Dec 27 23:16:48 2014 -0700 +++ b/chirp/ft1d.py Sun Dec 28 10:41:55 2014 -0700 @@ -16,6 +16,7 @@
import os import re +import string
from chirp import chirp_common, yaesu_clone, directory from chirp import bitwise @@ -317,19 +318,19 @@
#seekto 0x%04X; struct {
- u8 dst_callsign[6];
- u8 dst_callsign_ssid;
- u8 src_callsign[6];
- u8 src_callsign_ssid;
- u8 path_and_body[%d];
char dst_callsign[9];
char path[30];
u16 flags;
u8 seperator;
char body[%d]; } aprs_beacon_pkt[%d];
#seekto 0x137c4; struct {
- u8 unknown0;
- u8 dst_callsign[6];
- u8 flag;
- char dst_callsign[6]; u8 dst_callsign_ssid;
- u8 path_and_body[66];
- char path_and_body[66]; u8 unknown[70]; } aprs_message_pkt[60];
@@ -515,7 +516,7 @@ _mem_params = (0xFECA, # APRS beacon metadata address. 60, # Number of beacons stored. 0x1064A, # APRS beacon content address.
162, # Length of beacon data stored.
134, # Length of beacon data stored. 60) # Number of beacons stored. _has_vibrate = False _has_af_dual = True@@ -944,6 +945,54 @@
return menu
- def _get_aprs_msgs(self):
menu = RadioSettingGroup("aprs_msg", "APRS Messages")aprs_msg = self._memobj.aprs_message_pktfor index in range( 0, 60 ):if aprs_msg[index].flag != 255 :val = RadioSettingValueString(0, 9,str(aprs_msg[index].dst_callsign).rstrip("\xFF") +"-%d" % aprs_msg[index].dst_callsign_ssid )
rs = RadioSetting("aprs_msg.dst_callsign%d" % index,"Dst Callsign %d" % index, val)
menu.append(rs)val = RadioSettingValueString(0, 66,str(aprs_msg[index].path_and_body).rstrip("\xFF"))rs = RadioSetting("aprs_msg.path_and_body%d" % index,"Body", val)
menu.append(rs)return menu- def _get_aprs_beacons(self):
menu = RadioSettingGroup("aprs_beacons", "APRS Beacons")aprs_beacon = self._memobj.aprs_beacon_pktfor index in range( 0, 60 ):# There is probably a more pythonesque way to do thisif int( aprs_beacon[index].dst_callsign[0] ) != 255 :#print "DST callsign %s %d %s" % (aprs_beacon[index].dst_callsign, aprs_beacon[index].dst_callsign[0], list( str( aprs_beacon[index].dst_callsign )))
val = RadioSettingValueString(0, 9,str(aprs_beacon[index].dst_callsign).rstrip("\xFF"))
rs = RadioSetting("aprs_beacon.dst_callsign%d" % index,"DST Callsign %d" % index, val)
menu.append(rs)path = str( aprs_beacon[index].path ).replace( "\x00"," " )
path = ''.join(c for c in path if c instring.printable).strip()
path = str( path ).replace( "\xE0", "*" )#print "path %s %s" % ( path, list(path) )val = RadioSettingValueString(0, 32, path)rs = RadioSetting("aprs_beacon.path%d" % index,"Digipath", val)
menu.append(rs)body = str( aprs_beacon[index].body ).rstrip("\xFF")checksum = body[-2:]body = ''.join(s for s in body[:-2] if s instring.printable).replace( "\x0d", " " )
val = RadioSettingValueString(0, 134, body.strip())rs = RadioSetting("aprs_beacon.body%d" % index, "Body",val)
menu.append(rs)return menudef _get_aprs_rx_settings(self): menu = RadioSettingGroup("aprs_rx", "APRS Receive") aprs = self._memobj.aprs@@ -1378,6 +1427,8 @@ self._get_aprs_rx_settings(), self._get_aprs_tx_settings(), self._get_aprs_smartbeacon(),
self._get_aprs_msgs(),self._get_aprs_beacons(), self._get_dtmf_settings(), self._get_misc_settings(), self._get_scan_settings())
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
On 2014-12-29 03:35, Marco IZ3GME wrote:
Thanks Angus I have a pretty new FT1DE, will try your patches later today.
May I help you in any way with this new model? Do you want me to test something?
Hi Marco
I have an FT1DR and not sure what differences to the "E" variant are. One thing I think might differ is the _model string. To fix it up one of the variants may need to be sub-classed.
line 511 in chirp/ft1d.py _model = "AH44M"
By defining CHIRP_DEBUG in your environment, "export CHIRP_DEBUG=1" in Linux, the model number will get printed when you download from radio. If the number matches then the settings structs should line up and the settings will work.
If the models don't match then fix up line 511 so the download will work. You'll also need to check whether the settings in chirp match the radio. If the model number differs I'd be cautious about uploading to the radio until the settings have been checked
Things that are likely issues but I haven't tested yet:
1) setting AM or FM modes work but digital modes won't 2) scan settings are mostly untested.
Looking forward to feedback.
Angus
Hi Angus you email client have modified the structure of the patches, they can't be imported back to mercurial. I'm trying to correct them to import and test but you'd better resend them all to the list. Let me suggest to send them directly from mercurial via patchbomb instead of passing through email clients.
73 de IZ3GME Marco
On 29/12/2014 16:50, Angus Ainslie wrote:
On 2014-12-29 03:35, Marco IZ3GME wrote:
Thanks Angus I have a pretty new FT1DE, will try your patches later today.
May I help you in any way with this new model? Do you want me to test something?
Hi Marco
I have an FT1DR and not sure what differences to the "E" variant are. One thing I think might differ is the _model string. To fix it up one of the variants may need to be sub-classed.
line 511 in chirp/ft1d.py _model = "AH44M"
By defining CHIRP_DEBUG in your environment, "export CHIRP_DEBUG=1" in Linux, the model number will get printed when you download from radio. If the number matches then the settings structs should line up and the settings will work.
If the models don't match then fix up line 511 so the download will work. You'll also need to check whether the settings in chirp match the radio. If the model number differs I'd be cautious about uploading to the radio until the settings have been checked
Things that are likely issues but I haven't tested yet:
- setting AM or FM modes work but digital modes won't
- scan settings are mostly untested.
Looking forward to feedback.
Angus
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
On 2014-12-29 09:52, Marco IZ3GME wrote:
Hi Angus you email client have modified the structure of the patches, they can't be imported back to mercurial. I'm trying to correct them to import and test but you'd better resend them all to the list. Let me suggest to send them directly from mercurial via patchbomb instead of passing through email clients.
I'll give it another shot. I'm not very familiar with mercurial so it might take a while :)
On Mon, Dec 29, 2014 at 9:06 AM, Angus Ainslie angus@akkea.ca wrote:
On 2014-12-29 09:52, Marco IZ3GME wrote:
Hi Angus you email client have modified the structure of the patches, they can't be imported back to mercurial. I'm trying to correct them to import and test but you'd better resend them all to the list. Let me suggest to send them directly from mercurial via patchbomb instead of passing through email clients.
I'll give it another shot. I'm not very familiar with mercurial so it might take a while :)
The necessary commands are given here: http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess
Tom KD7LXL
On 2014-12-29 10:36, Tom Hayward wrote:
On Mon, Dec 29, 2014 at 9:06 AM, Angus Ainslie angus@akkea.ca wrote:
I'll give it another shot. I'm not very familiar with mercurial so it might take a while :)
The necessary commands are given here: http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess
Tom KD7LXL
If mercurial is already setup I'm sure they work wonderfully, unfortunately on my system it is not.
For the mercurial noob like me it might be nice to add
hg qrefresh --amend
To the list on that page
Angus, It works well for me... Here is my sample hgrc. It's for yahoo, but you get the idea:
$ cat .hg/hgrc [paths] default = http://d-rats.com/hg/chirp.hg
[ui] username = Jens Jensen af5mi@yahoo.com
[extensions] hgext.mq= hgext.patchbomb= hgext.crecord=/Users/jens/build/hgext/crecord/
[email] from = Jens Jensen af5mi@yahoo.com to = chirp_devel@intrepid.danplanet.com method = smtp
[smtp] host = smtp.mail.yahoo.com port = 465 tls = smtps verifycert = loose username = af5mi@yahoo.com
On Dec 29, 2014, at 11:43 AM, Angus Ainslie angus@akkea.ca wrote:
On 2014-12-29 10:36, Tom Hayward wrote:
On Mon, Dec 29, 2014 at 9:06 AM, Angus Ainslie angus@akkea.ca wrote:
I'll give it another shot. I'm not very familiar with mercurial so it might take a while :)
The necessary commands are given here: http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess
Tom KD7LXL
If mercurial is already setup I'm sure they work wonderfully, unfortunately on my system it is not.
For the mercurial noob like me it might be nice to add
hg qrefresh --amend
To the list on that page _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
On 12/28/2014 12:51 PM, Angus Ainslie wrote:
issue #967 - add aprs beacon and message parsing
The FT1DR stores the APRS messages and beacons in the clone. This patch displays those messages in the settings tab.
[...]
- based on the Yaesu vx8 driver
FWIW, The VX-8* also stored the APRS beacons and messages in the clone accessible part of the email. I never added anything to Chirp to access it, instead using a standalone Python script.
Sean Burford explored things further and had some better APRS parsing dump scripts (also python). He added additional APRS menu settings in issue #821
I don't have an FT1D to test with only a VX-8DR, but I would be interested to see if these bits can be back ported to the VX-8(D).
One hitch is that the memory layout for the APRS data is different on the original non-D VX-8, and the D version (VX-8D[RE]) due to storing 50 beacons vs. 40. It looks like the FT1D stores 60 beacons so it will also be different. It's been a while since I looked but I think the reason I didn't try to add the APRS beacons/messages to the memory structure definitions was not knowing how to handle the layout differences between the non-D and D in the same driver.
--Rob
On 2014-12-29 13:07, Robert Terzi wrote:
I don't have an FT1D to test with only a VX-8DR, but I would be interested to see if these bits can be back ported to the VX-8(D).
For the most part I tried to keep the names of the structure members the same even if I juggled the order so my changes "should" work with the VX-8 driver.
One hitch is that the memory layout for the APRS data is different on the original non-D VX-8, and the D version (VX-8D[RE]) due to storing 50 beacons vs. 40. It looks like the FT1D stores 60 beacons so it will also be different. It's been a while since I looked but I think the reason I didn't try to add the APRS beacons/messages to the memory structure definitions was not knowing how to handle the layout differences between the non-D and D in the same driver.
There is some code in the VX-8 driver to account for the varied number of records that I partially pulled into the FT1D driver. I didn't understand the code well enough to add an additional offset for the APRS messages.
What I did find was the layout of each record differed slightly in the FT1d from what was in the VX-8D.
participants (5)
-
Angus Ainslie -
Jens Jensen -
Marco IZ3GME -
Robert Terzi -
Tom Hayward