Yes! Here’s a diff of part of my change for anyone who may search for this in the future.
if _mem.freq_rx == _mem.freq_tx: mem.duplex = "" - mem.freq = _mem.freq_rx + mem.freq = int(_mem.freq_rx) elif _mem.freq_rx + _freq_offset == _mem.freq_tx: mem.duplex = "+" - mem.freq = _mem.freq_rx + mem.freq = int(_mem.freq_rx) mem.offset = _freq_offset elif _mem.freq_rx - _freq_offset == _mem.freq_tx: mem.duplex = "-" - mem.freq = _mem.freq_rx + mem.freq = int(_mem.freq_rx) mem.offset = _freq_offset else: mem.duplex = "split" - mem.freq = _mem.freq_rx - mem.offset = _mem.freq_tx + mem.freq = int(_mem.freq_rx) + mem.offset = int(_mem.freq_tx)
The IC-521 stores receive and transmit frequencies but not an offset.
On Nov 11, 2024, at 14:36, Dan Smith via Developers developers@lists.chirpmyradio.com wrote:
I’m (still) working on support for the Icom IC-F521/F621. Now I have a traceback that has me stumped. I get the error when I try to copy a memory to the clipboard. I’m running Chirp on Ubuntu 24.04.1 LTS (noble).
Traceback (most recent call last): File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1716, in <lambda> self.Bind(wx.EVT_MENU, lambda e: self.cb_copy(cut=False), copy_item) ^^^^^^^^^^^^^^^^^^^^^^^ File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1953, in cb_copy self.cb_copy_data(self.cb_copy_getdata(cut=cut)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/joseph/Devl/chirp/chirp/wxui/memedit.py", line 1936, in cb_copy_getdata memdata.SetData(pickle.dumps(payload)) ^^^^^^^^^^^^^^^^^^^^^ AttributeError: Can't pickle local object 'Processor.do_bitfield.<locals>.bitDE'
What might I have done (or failed to do) in my driver that has memedit so upset?
I did look through memedit.py and read about the pickle module (even played with making variables global) but no flash of enlightenment.
It's hard to guess about this with just a stack trace and no code. However, it's trying to serialize (pickle) all the memories it pulled from the driver according to the selected rows and it's failing to do that because there's something unserializable in there. Looks like you're including a bitDE from bitwise (i.e. some of the low-level memory objects) in a Memory object that you're returning. Since those *directly* reference a chunk of the memory map of a radio, it's definitely not cool to let that escape from your driver. Hard to say much more than that without code and a sample image though.
Second question.
Which Icom drivers make good examples? I’m using ic2820.py only because I have an IC-2820 radio.
The ic2820 driver is almost one of the oldest drivers in the tree. I certainly reference it a lot myself because it was, at one point, the most complete example available. Not sure that's really true or not anymore, but I wouldn't say it's a bad example.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com mailto:developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com mailto:developers-leave@lists.chirpmyradio.com