- Developers - lists.chirpmyradio.com

[chirp_devel] FT-7800 memory banks
by Jon Kåre Hellan 19 May '11

19 May '11

I've got an FT-7800, and have figured out how banks are stored. Starting at 0x6c48, there's a 128 byte bitmap for each bank. Byte 17 is set if channel 17 belongs to the bank, etc. There is no flag telling which banks are in use. Banks are named BANK 1 .. BANK20, but these names are immutable, i.e. they aren't stored in the image, so the user cannot change them. The chirp UI should show them as immutable. Patch attached for the curious. Dan, once you get back from Dayton, will you want the Yaesu memory bank patches as a single patch or one patch per radio? Regards Jon LA4RT

2 1

Re: [chirp_devel] Repeaterbook.com
by bobg＠plugsinc.com 19 May '11

19 May '11

Bob here...developer of RFinder... > Have anyone here looked at repeaterbook.com at all? >>Heh, free, a sane web interface, and they have an iOS app too. I wonder >>how comprehensive the database is. It also makes me wonder what the >>RFinder value proposition will be :) Honelstly I never saw it before...it isn't found easily on search engines...my first impression is that it is similar paradigm to the ARRL Repeater Dir...his sitename is self descriptive...our db is geolocation enbabled...I did not look deeply into his data but at first glance he is not geolo enabled as when I drilled into his data there were no lat/Lon's...mapping seems approximate and based on city. RFinder for iOS code cuts this summer. > It also has some areas that need work. The guy who wrote the site > is a self-taught php developer. He's been pretty open to the > suggestions/changes that I've proposed. >>It returns queries semi-instantly, so at least he has a grasp on the >>backend. There is some information in there on "paper repeaters" in my >>area that are coordinated, but never got put up. Looks like some of the >>data was imported from the local coordination body (gotta get it >>somehow, I suppose). His queries are quick...that is our weakness and we are addressing that. We will change our DB this summer...the web services will be functionally the same so there will be no front end programming changes (I think, LOL)....we prototyped this but did not expect the popularity we have achieved in 6 weeks...600 users already!!! We were trying to get out the gate...bottom line we know there is a performance issue and it is being addressed. > There are a couple of export formats currently supported. I think we > have a reasonable chance of getting chirp csv export format added. > (Chirp native xml is in the range of possibilities too of course) >>That would be great. Maybe you can bring it up if you already have a >>relationship with him? It'd be even nicer to have a web services >>interface to the query, but that would cut down on his ad revenue. While I love a good competition, our scope is different from his...we are creating the first Worldwide Repeater Directory...I don't belittle anyone's previous attempts at creating online repeater databases, but we are not regional. The data is user maintained (on the android platform you can request changes to an entry, and hopefully by the weekend add a new repeater...this will migrate out to interactive web and web service). If you want something on RFinder's back end, just ask. We are already a web service. We started there...interactive web is not our primary interface although it exists from and admin perspective right now and will be end after we change DB's. I don't want to sound like a megalomaniac, but....One Master Database. Please support this...for obvious reasons. 'Nuff said. > There are lots of repeater databases out there, but most seem to > have put little to no thought into the data maintenance process. >>Yeah, I've just never been one to preload my radio like that before >>traveling, so I'm usually not on the lookout for stuff like this. I >>guess some people are, though. We put end user maintenance in within a week of publishing to the market. By user request. Again, we will allow adding interactively. We have adding by batch already although it is an email process currently. We have been asked by reps of Chile, Brazil, Israel, Switzerland, South Africa and Sweden so far to work with them on improving the data. We have provided their data in our spreadsheet format for them to edit and return...all are done except SA and Sweden. > All the effort seems to go into the GUI and the database/site quickly > looses relevance as the data slowly rots. > > Thoughts? Comments? >>Yeah, the RFinder guys seem to have no consistency checks in the data >>they put in (or imported, or whatever). Tone values with transposed >>digits and what-not. Does the repeater book site handle that better? >>Requiring a human editor is a nice idea, but weeding out invalid tones >>and things of that sort is much better done in code, I'd say. We have been working over the last couple of weeks to fix inconsistencies in the data. We have an algorithm worked out to fix the PL's. Our data is sourced from dozens of places....once Dan pointed out the inconsistencies with the PL's our new mode is to validate on import. We have to retroactively fix what's wrong though. Work in progress. >>Unless nobody finds it interesting/useful, I think the integrated >>RFinder client functionality in chirp is still worthwhile. Would you >>agree, or not? I sure hope you guys understand we are in this for the long haul. We are developing a solid business model on it that will allow for its improvement and continued development. Creating and maintaining RFinder and The Worldwide Repeater Directory is not a hobby. In order for it to be truly successful it cannot be. Amateur Radio on Earth needs it. It's not perfect and may never be, but we will do our best to make it great. Thanks for your support. _______________________________________________________________ RFinder - The Worldwide Repeater Directory Bob Greenberg W2CYK 516.807.0697 Mobile 631.594.2555 Desk/Mobile Simulring 631.389.2508 Fax "When all else fails...Amateur Radio" ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 1

Re: [chirp_devel] Repeaterbook.com
by bobg＠w2cyk.net 19 May '11

19 May '11

Bob here...developer of RFinder... > Have anyone here looked at repeaterbook.com at all? >>Heh, free, a sane web interface, and they have an iOS app too. I wonder >>how comprehensive the database is. It also makes me wonder what the >>RFinder value proposition will be :) Honelstly I never saw it before...it isn't found easily on search engines...my first impression is that it is similar paradigm to the ARRL Repeater Dir...his sitename is self descriptive...our db is geolocation enbabled...I did not look deeply into his data but at first glance he is not geolo enabled as when I drilled into his data there were no lat/Lon's...mapping seems approximate and based on city. RFinder for iOS code cuts this summer. > It also has some areas that need work. The guy who wrote the site > is a self-taught php developer. He's been pretty open to the > suggestions/changes that I've proposed. >>It returns queries semi-instantly, so at least he has a grasp on the >>backend. There is some information in there on "paper repeaters" in my >>area that are coordinated, but never got put up. Looks like some of the >>data was imported from the local coordination body (gotta get it >>somehow, I suppose). His queries are quick...that is our weakness and we are addressing that. We will change our DB this summer...the web services will be functionally the same so there will be no front end programming changes (I think, LOL)....we prototyped this but did not expect the popularity we have achieved in 6 weeks...600 users already!!! We were trying to get out the gate...bottom line we know there is a performance issue and it is being addressed. > There are a couple of export formats currently supported. I think we > have a reasonable chance of getting chirp csv export format added. > (Chirp native xml is in the range of possibilities too of course) >>That would be great. Maybe you can bring it up if you already have a >>relationship with him? It'd be even nicer to have a web services >>interface to the query, but that would cut down on his ad revenue. While I love a good competition, our scope is different from his...we are creating the first Worldwide Repeater Directory...I don't belittle anyone's previous attempts at creating online repeater databases, but we are not regional. The data is user maintained (on the android platform you can request changes to an entry, and hopefully by the weekend add a new repeater...this will migrate out to interactive web and web service). If you want something on RFinder's back end, just ask. We are already a web service. We started there...interactive web is not our primary interface although it exists from and admin perspective right now and will be end after we change DB's. I don't want to sound like a megalomaniac, but....One Master Database. Please support this...for obvious reasons. 'Nuff said. > There are lots of repeater databases out there, but most seem to > have put little to no thought into the data maintenance process. >>Yeah, I've just never been one to preload my radio like that before >>traveling, so I'm usually not on the lookout for stuff like this. I >>guess some people are, though. We put end user maintenance in within a week of publishing to the market. By user request. Again, we will allow adding interactively. We have adding by batch already although it is an email process currently. We have been asked by reps of Chile, Brazil, Israel, Switzerland, South Africa and Sweden so far to work with them on improving the data. We have provided their data in our spreadsheet format for them to edit and return...all are done except SA and Sweden. > All the effort seems to go into the GUI and the database/site quickly > looses relevance as the data slowly rots. > > Thoughts? Comments? >>Yeah, the RFinder guys seem to have no consistency checks in the data >>they put in (or imported, or whatever). Tone values with transposed >>digits and what-not. Does the repeater book site handle that better? >>Requiring a human editor is a nice idea, but weeding out invalid tones >>and things of that sort is much better done in code, I'd say. We have been working over the last couple of weeks to fix inconsistencies in the data. We have an algorithm worked out to fix the PL's. Our data is sourced from dozens of places....once Dan pointed out the inconsistencies with the PL's our new mode is to validate on import. We have to retroactively fix what's wrong though. Work in progress. >>Unless nobody finds it interesting/useful, I think the integrated >>RFinder client functionality in chirp is still worthwhile. Would you >>agree, or not? I sure hope you guys understand we are in this for the long haul. We are developing a solid business model on it that will allow for its improvement and continued development. Creating and maintaining RFinder and The Worldwide Repeater Directory is not a hobby. In order for it to be truly successful it cannot be. Amateur Radio on Earth needs it. It's not perfect and may never be, but we will do our best to make it great. Thanks for your support. _______________________________________________________________ RFinder - The Worldwide Repeater Directory Bob Greenberg W2CYK 516.807.0697 Mobile 631.594.2555 Desk/Mobile Simulring 631.389.2508 Fax "When all else fails...Amateur Radio" ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

1 0

[chirp_devel] [RFC] Convert to "integral hertz" for frequency storage
by Dan Smith 18 May '11

18 May '11

Hi all, Right now, chirp stores frequencies as a floating point number. That's convenient (at times) but is fatally flawed because the internal representation is Base-2. That leads to odd behavior like this: $ python >>> 130.8 * 100 13080.000000000002 There are many places where this bites users and results in very odd behavior. The correct way to fix this is to store the frequency in units of Hertz, which we can represent cleanly with an integer. This is a straightforward change, but a wide-sweeping one. I've spent many hours doing my best to carefully convert every driver in the tree to this mode of operation, as well as all the UI elements. The automated tests have made this much easier, but there is still the extreme possibility for errors. I would really (really) appreciate it if you developer-types could clone the following tree and bang around on it a bit: http://d-rats.com/hg/hgwebdir.cgi/chirp-intHz.hg/ After an initial sniff-test here, I'll push it into the main repository and hope for some more wide-spread testing. Thanks! -- Dan Smith www.danplanet.com KK7DS

3 4

Re: [chirp_devel] #112: Memory bank support for VX-8
by Robert Terzi 18 May '11

18 May '11

Is the first step documenting how the VX-8 banks are stored in the memory image? Has anyone started on this with the VX-8 or similar Yaesu? Is there bank support in chirp for any other radio? On 5/13/2011 5:25 AM, CHIRP Tracker wrote: > #112: Memory bank support for VX-8 > ------------------------------+--------------------------------------------- > Reporter: jesper@… | Type: Feature > Status: new | Priority: Functionality > Milestone: | Component: Bank Editor > Version: 0.1.11 | Keywords: > Platform: Linux | > ------------------------------+--------------------------------------------- > Chirp currently doesn't seem to support memory bank editing in Yaesu VX-8, > though the VX-8 does actually have memory banks. Would it be possible to > add support for it in chirp? >

4 14

[chirp_devel] [PATCH] Add RFinder support as an import source
by Dan Smith 17 May '11

17 May '11

# HG changeset patch # User Dan Smith <dsmith(a)danplanet.com> # Date 1305671333 25200 # Node ID bf2e12513c27a3b685009ad6561850c8a83f7fca # Parent 72131a755f0b41dc94556813517da998eeeb1759 Add RFinder support as an import source RFinder is a subscription-based repeater database. This adds an item under the Radio menu for "Import from RFinder". diff -r 72131a755f0b -r bf2e12513c27 build/version --- a/build/version Mon May 16 16:41:09 2011 -0700 +++ b/build/version Tue May 17 15:28:53 2011 -0700 @@ -1,1 +1,1 @@ -0.1.11 +0.1.11rfinder3 diff -r 72131a755f0b -r bf2e12513c27 chirp/__init__.py --- a/chirp/__init__.py Mon May 16 16:41:09 2011 -0700 +++ b/chirp/__init__.py Tue May 17 15:28:53 2011 -0700 @@ -15,4 +15,4 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. -CHIRP_VERSION="0.1.11" +CHIRP_VERSION="0.1.11rfinder2" diff -r 72131a755f0b -r bf2e12513c27 chirp/directory.py --- a/chirp/directory.py Mon May 16 16:41:09 2011 -0700 +++ b/chirp/directory.py Tue May 17 15:28:53 2011 -0700 @@ -22,7 +22,7 @@ from chirp import kenwood_live, tmv71, thd72 from chirp import alinco from chirp import wouxun -from chirp import xml, chirp_common, csv, util +from chirp import xml, chirp_common, csv, util, rfinder DRV_TO_RADIO = { @@ -116,6 +116,12 @@ raise Exception("Unsupported model") def get_radio_by_image(image_file): + if image_file.startswith("rfinder://"): + method, _, email, passwd, lat, lon = image_file.split("/") + rf = rfinder.RFinderRadio(None) + rf.set_params(float(lat), float(lon), email, passwd) + return rf + if image_file.lower().endswith(".chirp"): return xml.XMLRadio(image_file) diff -r 72131a755f0b -r bf2e12513c27 chirp/rfinder.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/chirp/rfinder.py Tue May 17 15:28:53 2011 -0700 @@ -0,0 +1,161 @@ +# Copyright 2011 Dan Smith <dsmith(a)danplanet.com> +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +import urllib +import hashlib + +from chirp import chirp_common, CHIRP_VERSION + +SCHEMA = [ + "ID", + "TRUSTEE", + "OUTFREQUENCY", + "CITY", + "STATE", + "COUNTRY", + "LATITUDE", + "LONGITUDE", + "CLUB", + "DESCRIPTION", + "NOTES", + "RANGE", + "OFFSETSIGN", + "OFFSETFREQ", + "PL", + "DCS", + "REPEATERTYPE", + "BAND", + "IRLP", + "ECHOLINK", + "DOC_ID", + ] + +class RFinderParser: + def __init__(self): + self.__memories = [] + self.__cheat = {} + + def fetch_data(self, lat, lon, email, passwd): + args = { + "lat" : "%7.5f" % lat, + "lon" : "%8.5f" % lon, + "email" : urllib.quote_plus(email), + "pass" : hashlib.md5(passwd).hexdigest(), + "vers" : "CH%s" % CHIRP_VERSION, + } + + url = "http://sync.rfinder.net/radio/repeaters.nsf/getlocal?openagent&%s"\ + % "&".join(["%s=%s" % (k,v) for k,v in args.items()]) + + f = urllib.urlopen(url) + data = f.read() + f.close() + + return data + + def parse_line(self, line): + mem = chirp_common.Memory() + + _vals = line.split("|") + + vals = {} + for i in range(0, len(SCHEMA)): + vals[SCHEMA[i]] = _vals[i] + self.__cheat = vals + + mem.name = vals["TRUSTEE"] + mem.freq = float(vals["OUTFREQUENCY"]) + if vals["OFFSETSIGN"] != "X": + mem.duplex = vals["OFFSETSIGN"] + if vals["OFFSETFREQ"]: + mem.offset = abs(float(vals["OFFSETFREQ"])) + + if vals["PL"] and vals["PL"] != "0": + mem.rtone = float(vals["PL"]) + mem.tmode = "Tone" + elif vals["DCS"] and vals["DCS"] != "0": + mem.dtcs = int(vals["DCS"]) + mem.tmode = "DTCS" + + return mem + + def parse_data(self, data): + number = 1 + for line in data.split("\n"): + if line.startswith("<"): + continue + elif not line.strip(): + continue + try: + mem = self.parse_line(line) + mem.number = number + number += 1 + self.__memories.append(mem) + except Exception, e: + print "Error in record %s:" % self.__cheat["DOC_ID"] + print e + print self.__cheat + print "\n\n" + + def get_memories(self): + return self.__memories + +class RFinderRadio(chirp_common.Radio): + VENDOR = "ITWeRKS" + MODEL = "RFinder" + + def __init__(self, *args, **kwargs): + chirp_common.Radio.__init__(self, *args, **kwargs) + + self._lat = 0 + self._lon = 0 + self._call = "" + self._email = "" + + self._rfp = None + + def set_params(self, lat, lon, call, email): + self._lat = lat + self._lon = lon + self._call = call + self._email = email + + def do_fetch(self): + self._rfp = RFinderParser() + self._rfp.parse_data(self._rfp.fetch_data(self._lat, self._lon, self._call, self._email)) + + def get_features(self): + if not self._rfp: + self.do_fetch() + + rf = chirp_common.RadioFeatures() + rf.memory_bounds = (1, len(self._rfp.get_memories())) + return rf + + def get_memory(self, number): + if not self._rfp: + self.do_fetch() + + return self._rfp.get_memories()[number-1] + +if __name__ == "__main__": + import sys + + rfp = RFinderParser() + data = rfp.fetch_data(45.525, -122.9164, "KK7DS", "dsmith(a)danplanet.com") + rfp.parse_data(data) + + for m in rfp.get_memories(): + print m diff -r 72131a755f0b -r bf2e12513c27 chirpui/mainapp.py --- a/chirpui/mainapp.py Mon May 16 16:41:09 2011 -0700 +++ b/chirpui/mainapp.py Tue May 17 15:28:53 2011 -0700 @@ -75,7 +75,7 @@ for i in ["cancelq"]: set_action_sensitive(i, eset is not None and not mmap_sens) - for i in ["export", "import", "close", "columns"]: + for i in ["export", "import", "close", "columns", "rfinder"]: set_action_sensitive(i, eset is not None) def ev_status(self, editorset, msg): @@ -394,6 +394,67 @@ count = eset.do_import(filen) reporting.report_model_usage(eset.rthread.radio, "import", count > 0) + def do_rfinder_prompt(self): + fields = {"1Email" : (gtk.Entry(), + lambda x: "@" in x), + "2Password" : (gtk.Entry(), + lambda x: x), + "3Latitude" : (gtk.Entry(), + lambda x: float(x) < 90 and float(x) > -90), + "4Longitude": (gtk.Entry(), + lambda x: float(x) < 180 and float(x) > -180), + } + + d = inputdialog.FieldDialog(title="RFinder Login", parent=self) + for k in sorted(fields.keys()): + d.add_field(k[1:], fields[k][0]) + fields[k][0].set_text(CONF.get(k[1:], "rfinder") or "") + fields[k][0].set_visibility(k != "2Password") + + while d.run() == gtk.RESPONSE_OK: + valid = True + for k in sorted(fields.keys()): + widget, validator = fields[k] + try: + if validator(widget.get_text()): + CONF.set(k[1:], widget.get_text(), "rfinder") + continue + except Exception: + pass + common.show_error("Invalid value for %s" % k[1:]) + valid = False + break + + if valid: + d.destroy() + return True + + d.destroy() + return False + + def do_rfinder(self): + self.window.set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH)) + if not self.do_rfinder_prompt(): + self.window.set_cursor(None) + return + + lat = CONF.get_float("Latitude", "rfinder") + lon = CONF.get_float("Longitude", "rfinder") + passwd = CONF.get("Password", "rfinder") + email = CONF.get("Email", "rfinder") + + # Do this in case the import process is going to take a while + # to make sure we process events leading up to this + gtk.gdk.window_process_all_updates() + while gtk.events_pending(): + gtk.main_iteration(False) + + eset = self.get_current_editorset() + count = eset.do_import("rfinder://%s/%s/%f/%f" % (email, passwd, lat, lon)) + reporting.report_model_usage(eset.rthread.radio, "import", count > 0) + + self.window.set_cursor(None) + def do_export(self): types = [("CSV Files (*.csv)", "csv"), ("CHIRP Files (*.chirp)", "chirp"), @@ -537,6 +598,8 @@ self.do_close() elif action == "import": self.do_import() + elif action == "rfinder": + self.do_rfinder() elif action == "export": self.do_export() elif action == "about": @@ -591,7 +654,8 @@ <menu action="radio" name="radio"> <menuitem action="download"/> <menuitem action="upload"/> - <menu action="recent" name="recent"/> + <separator/> + <menuitem action="rfinder"/> <separator/> <menuitem action="cancelq"/> </menu> @@ -622,6 +686,7 @@ ('upload', None, "Upload To Radio", "<Alt>u", None, self.mh), ('import', None, 'Import', "<Alt>i", None, self.mh), ('export', None, 'Export', "<Alt>e", None, self.mh), + ('rfinder', None, "Import from RFinder", None, None, self.mh), ('export_chirp', None, 'CHIRP Native File', None, None, self.mh), ('export_csv', None, 'CSV File', None, None, self.mh), ('cancelq', gtk.STOCK_STOP, None, "Escape", None, self.mh),

2 3

[chirp_devel] Some more VX-6 bits
by Jon K Hellan 13 May '11

13 May '11

I've added some extra bits I know about to VX-6 channel memories. I reverse engineered a good part of the VX-6 image format some years ago, but never followed up on it. See http://www.ha19.no/la4rt/vx-6-protocol.html. The attached patch modifies the memory format in vx6.py, with a separate comment block to explain what's going on. The fields for Power and half deviation should be useful. I haven't tried to tie the bits up to the program logic. Regards Jon LA4RT Jon K Hellan, Trondheim, Norway

3 6

[chirp_devel] CSV Power Levels
by Dan Smith 10 May '11

10 May '11

Hi all, I thought I'd post an RFC patch for supporting power levels in the CSV driver for some discussion. The lack of this feature is an oft-mentioned item with folks. I think the commit message covers the details, but let me know if you have any questions. I'm hoping to get some ACK/NAK or discussion about this before I put it into the tree. Thanks! -- Dan Smith www.danplanet.com KK7DS

1 0

[chirp_devel] Couple small patches for Wouxun
by Louie Ilievski 03 May '11

03 May '11

All, I've attached a couple changes for Wouxun. The first change defines the busy channel lockout bit in the memory map and defaults it to being off (I was annoyed on a road trip this weekend when I discovered some of the channels I had recently programmed had it enabled which can make talking on repeaters a pain). There is no column yet for this and I didn't find any other supported radio at a glance that had a similar feature so I figured for now it was best to just give it a default and if we want to support it in the UI at some point then it can be updated. The other change just fixes the character set to include the few supported special characters at the end instead of all question marks. Memory channel names that I had programmed directly into the radio with spaces were being imported into CHIRP with question marks in place of the spaces. Thanks, ~Lou

2 1

[chirp_devel] FYI: KC8UNJ commander software now supports Wouxun. KG-UV[123]
by Robert Terzi 02 May '11

02 May '11

It was announced on the Wouxun yahoo group list that the KC8UNJ Commander software now has a version for wouxun KG-UV[123] This is free software, but not open source, and is windows only. Someone mentioned it's implemented in Visual basic, which I don't know if that's correct or not. I mention it here as a somewhat mild FYI. KC8UNJ's commander software is available for radios from Yaesu, ICom, and now Wouxun. However, there are separate packages for each radio, and per radio specific formats. At least according to the read-me even the csv is considered radio specific. It does support importing/exporting the .tw files that the wouxun supplied software uses. I don't know if there is anything useful to learn from the software. I was hoping it might have something to learn from in terms of cross radio file format, but that doesn't appear to be the case. As far as I've seen Chirp seems to be leading the way. --Rob

1 0