The CHIRP-next has a menu item allowing to show the debug log. It seems to be in a private /tmp location with a name starting “chirp_debug"
When I run “./chirpwx.py” from my development copy of CHIRP (with developer mode turned on) … NOW where can I find the debug log? If I knew its name, I suppose I could run find(1) to get it. If it needs to be named in some parameter so I can access it, what’s the parameter? Does it require a redirect from stderr?
I have been using developer mode simply to browse the state of my data. That’s pretty useful. I see there’s also an option to “interact with the driver”, which gives me a python “>>>” prompt with an introduction: WARNING: Going to interact with radio at the console Locals are: main, radio
What are interesting things one can do with the driver interaction? Can one set breakpoints? Modify code on-the-fly? Inspect or change program state other than the data seen by the browser? I am just barely aware enough to ask python for "dir(radio)” and for individual items in my driver… what next?
Thanks for any direction or suggestions. ______ Declan Rieb WD5EQY wd5eqy@arrl.net
The CHIRP-next has a menu item allowing to show the debug log. It seems to be in a private /tmp location with a name starting “chirp_debug"
When I run “./chirpwx.py” from my development copy of CHIRP (with developer mode turned on) … NOW where can I find the debug log? If I knew its name, I suppose I could run find(1) to get it. If it needs to be named in some parameter so I can access it, what’s the parameter? Does it require a redirect from stderr?
If you're running it from a tty, it just logs directly to the console, so no debug log is created. If you want one, redirect stdin to something other than a tty (so "./chipwxpy </dev/null" or something). But, if you're working on it, you probably want it to just log to the console, or at least, I do.
I have been using developer mode simply to browse the state of my data. That’s pretty useful. I see there’s also an option to “interact with the driver”, which gives me a python “>>>” prompt with an introduction: WARNING: Going to interact with radio at the console Locals are: main, radio
What are interesting things one can do with the driver interaction? Can one set breakpoints? Modify code on-the-fly? Inspect or change program state other than the data seen by the browser? I am just barely aware enough to ask python for "dir(radio)” and for individual items in my driver… what next?
The "radio" object is your driver class's instance, so you can do whatever you want with it. You don't need to use this interface to use pdb (although you probably can, I'm not a debugger guy). I usually use it when I'm trying to figure out something with a driver and I want to run commands directly against the driver, like getting a memory, making some specific change to it (that might be hard to do with the GUI) and then set it back to see the effect.
It's really one of those things where if you have to ask, it's probably not very useful to you :)
--Dan
Thanks, Dan for the prompt answers. I’ll abandon the “interaction" tack.
My questions were prompted by a desire to have my driver support multiple file formats. (Clearly, the CHIRP format works, and the Yaesu Adds FT-1D format works. I’d like to add the Yaesu SD-card format to be able to read the memory image that the radio can read/write already.) Presently, I’m trying by simply adding an entry to FORMATS:
FORMATS = [directory.register_format('FT1D ADMS-6', '*.ft1d'), directory.register_format('FT1D SDcard', '*.sdc1’)]
And hoping that the new format (“.sdc1”) could be recognized. But when I request to open such a file, it always receives ERROR: <function ChirpMain.open_file at 0x10cf2c540>: Unknown file format With no indication of exactly where or what I’ve done to the CHIRP. There’s nothing in stdout but that! I had thought that log messages had been swallowed somehow. I was wrong: apparently there are none.
So, what IS the “correct” way to register a second file format? Since the SD-card image is simply the radio memory (without the CHIRP prefix,) it’d seem to be a snap to fake or ignore the prefix and put the memories into the correct locations in CHIRP.
On Aug 19, 2024, at 20:10, Dan Smith via Developers developers@lists.chirpmyradio.com wrote:
<snip> It's really one of those things where if you have to ask, it's probably not very useful to you :)
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
And hoping that the new format (“.sdc1”) could be recognized. But when I request to open such a file, it always receives ERROR: <function ChirpMain.open_file at 0x10cf2c540>: Unknown file format With no indication of exactly where or what I’ve done to the CHIRP. There’s nothing in stdout but that! I had thought that log messages had been swallowed somehow. I was wrong: apparently there are none.
It's hard to say without seeing your code, but... did you make your match_model() also indicate that those files match?
So, what IS the “correct” way to register a second file format? Since the SD-card image is simply the radio memory (without the CHIRP prefix,) it’d seem to be a snap to fake or ignore the prefix and put the memories into the correct locations in CHIRP.
I'm not sure what "CHIRP prefix" you mean exactly. There's a "metadata footer" that chirp adds to image files, but most drivers are (should be) 1:1 with the memory mapping of the radio until the end of memory and the metadata footer starts.
--Dan
Bingo. Thanks again.
Oh my: the logic is in TWO places! D’oh! I should have noticed that.match_model is also required to reflect directory.register_format. *sigh*
The CHIRP .img file for Yaesu FT2D has a prefix ‘AH60M’ followed by 0xc0fd010002. I do see the postpended CHIRP metadata footer that’s mostly in binhex format. The equivalent Yaesu Adms .ft2d filehas 22 hex bytes followed by 0xc0fd010002 (same digits; I think the valid length of the image is 0x0010fdc0. Adms also postpends a metadata footer. And if I read in a .ft2d file, I can write a CHIRP .img file, and it’ll have BOTH metadatas. The FT-3D Adms does it differently. Another *sigh*
The SD-card image has none of these prefixes.
______ Declan Rieb WD5EQY wd5eqy@arrl.net
On Aug 20, 2024, at 16:02, Dan Smith via Developers developers@lists.chirpmyradio.com wrote:
<SNIP> It's hard to say without seeing your code, but... did you make your match_model() also indicate that those files match?
<SNIP> I'm not sure what "CHIRP prefix" you mean exactly. There's a "metadata footer" that chirp adds to image files, but most drivers are (should be) 1:1 with the memory mapping of the radio until the end of memory and the metadata footer starts.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
participants (2)
-
Dan Smith -
Declan Rieb