Updating TD-H3 for more recent variants
Hi! I'm new to ham radio in general and chirp in particular, so please bear with me.
I have a new TD-H3 that allows me to enable 1.25m TX. I tried to chirp it to set up some local 1.25m repeaters, but could not because of the _txbands limitation. (It also allows setting TX on some bands that aren't ham bands in the US.) I would like to chirp those 1.25m repeaters into the unit, which would require me to update chirp.
It seems obvious to this naive newcomer that the approach is to dump images modifying each of the settings not currently present to reverse them, and add them to the MEM_FORMAT, then add them to settings handling, after which I should be able to update _txbands to include frequency ranges that have been enabled on the particular HT being chirped, including setting those TX modes in settings.
However, I'm confused about how to deal with at least two things.
1. While the menu on the HT has setting 42. Version "AM_240316 I don't see anything like that in the image I downloaded, so it's not clear to me whether I can make the new settings conditional on some new-enough firmware version.
2. There's only one MEM_FORMAT for the radios supported in tdh8.py and I have no idea whether the formats have diverged between radios because I have only a TD-H3 to play with.
I'm aware that I don't know what I don't know and haven't tried modifying anything yet.
I have a new TD-H3 that allows me to enable 1.25m TX.
What does that mean? Is there a setting in the radio? That would surprise me, but...
I tried to chirp it to set up some local 1.25m repeaters, but could not because of the _txbands limitation. (It also allows setting TX on some bands that aren't ham bands in the US.) I would like to chirp those 1.25m repeaters into the unit, which would require me to update chirp.
Why not just put the radio into unrestricted mode where there are basically no limits?
It seems obvious to this naive newcomer that the approach is to dump images modifying each of the settings not currently present to reverse them, and add them to the MEM_FORMAT, then add them to settings handling, after which I should be able to update _txbands to include frequency ranges that have been enabled on the particular HT being chirped, including setting those TX modes in settings.
Maybe this is the answer to the question above -- there's some setting in the radio that lets you enable this band? Is it in the radio itself or the software?
If there are settings, then sure, you can decode them so they're accessible in chirp.
However, I'm confused about how to deal with at least two things.
- While the menu on the HT has setting 42. Version "AM_240316 I don't see anything like that in the image I downloaded, so it's not clear to me whether I can make the new settings conditional on some new-enough firmware version.
If not then probably not, yeah. _Is_ this new behavior from a new firmware version? If so, do you have a link to a changelog or something that explains it?
Do we get the firmware version during the clone exchange perhaps? If so, we can memorize it at that point for later.
- There's only one MEM_FORMAT for the radios supported in tdh8.py and I have no idea whether the formats have diverged between radios because I have only a TD-H3 to play with.
There are two, one for the H3 and one for the H8. No structural changes due to firmware versions have happened that I know of.
I have one of each that I can test with, but I'm not super familiar with them. It's very important that we not break older firmware versions if this really is new, as you indicate, so thanks for already thinking in that mode.
--Dan
On Fri, Nov 1, 2024 at 11:25 PM Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
I have a new TD-H3 that allows me to enable 1.25m TX.
What does that mean? Is there a setting in the radio? That would surprise me, but...
Yes, the radio now has among its settings: 52.200TX (default OFF) 53.350TX (default OFF) 54.500TX (default off)
I haven't yet done a complete comparison to see all the settings that are new relative to what's in chirp.
42.Version is set to HAM_240416 but of course that's not a setting that I can change.
I tried to chirp it to set up some local 1.25m repeaters, but could not
because of the _txbands limitation. (It also allows setting TX on some bands that aren't ham bands in the US.) I would like to chirp those 1.25m repeaters into the unit, which would require me to update chirp.
Why not just put the radio into unrestricted mode where there are basically no limits?
Because I'd rather not accidentally transmit on bands that I'm not permitted to. I'm a chicken, but also human and make mistakes, and at least as a brand new ham I appreciate the training wheels...
If not then probably not, yeah. _Is_ this new behavior from a new firmware version? If so, do you have a link to a changelog or something that explains it?
Heh. If anyone knows where tidradio would keep such things, I'm all ears/eyes. I haven't seen that the firmware is upgradeable either. I understand that earlier versions had excessive spurious emissions on 1.25, that tidradio said they were addressing that, and as I understand it they have enabled this setting in firmware for hardware for which they fixed that problem. This is all third-hand.
Do we get the firmware version during the clone exchange perhaps? If so, we can memorize it at that point for later.
I've been looking and so far I don't see it.
I can't change it to reverse it to be sure, but it's not obviously present as a string, or as three nearly adjacent bytes with values 0x4, 0x10, and 0x18 in the dump anywhere.
I saved a factory settings image first thing after powering it on, and I'm happy to provide that to you if you like. If I succeed at this, I presume I'd include it in my PR.
Your sample image in the repository starts: 00000000 50 33 31 31 38 33 ff ff ff ff ff ff ff ff ff ff |P31183..........|
My factory image, as well as every other dump I've checked that I've done, starts: 00000000 50 33 31 31 38 35 ff ff 00 00 00 00 00 00 00 00 |P31185..........|
If we could get more dumps with different firmware versions and settings, we might be able to map P3118? to different feature sets.
- There's only one MEM_FORMAT for the radios supported in tdh8.py and I
have no idea whether the formats have diverged between radios because I have only a TD-H3 to play with.
There are two, one for the H3 and one for the H8. No structural changes due to firmware versions have happened that I know of.
Yeah, I realized my eyes had glazed over and missed the separate settings after I sent that message. Oops.
I have one of each that I can test with, but I'm not super familiar with them. It's very important that we not break older firmware versions if this really is new, as you indicate, so thanks for already thinking in that mode.
I have plenty of kernel driver experience with variant firmware, so I'm quite sensitive to this potential. ☺
I'll hope I don't have to declare a whole new radio for this. But first I should get this working on my radio, and then if that succeeds we can talk about what a PR should look like to be acceptable.
Because I'd rather not accidentally transmit on bands that I'm not permitted to. I'm a chicken, but also human and make mistakes, and at least as a brand new ham I appreciate the training wheels...
Okay, but none of the limits seem to line up with the actual band edges anyway, but fair enough.
If we could get more dumps with different firmware versions and settings, we might be able to map P3118? to different feature sets.
Perhaps.
I'll hope I don't have to declare a whole new radio for this. But first I should get this working on my radio, and then if that succeeds we can talk about what a PR should look like to be acceptable.
I really *really* hate having to add new user-visible options in the download box for things like this, so I'd really want to avoid that at all costs.
--Dan
On Sat, Nov 2, 2024 at 12:13 AM Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
If we could get more dumps with different firmware versions and
settings, we might be able to map P3118? to different feature sets.
Perhaps.
I'll look at how you've implemented other guards and try to sing from the same songsheet. I've asked on Mastodon for more image dump headers and firmware version information. 🤞
I'll look at how you've implemented other guards and try to sing from the same songsheet.
There's a lot of prior art, but not all of which I'd recommend. With a 15+ year code base, there are lots of things we've done/tried that I wouldn't recommend. Let's figure out how we're going to tell them apart and then we can figure out the best plan.
Also, if the radio doesn't balk at them being in the radio as TX-able even if the older firmwares refuse, that might just be the best plan. CHIRP won't tell the user they're putting in a channel they won't be able to transmit on, but not all the drivers can/do provide that feedback. This driver does, mostly because of the three (four now?) variants.
--Dan
Ah, so KISS is an appropriate thing to attempt here. Since you have an earlier version to test with, I'll first plan to just implement at least some of the new settings I find, and let you tell me whether your older radio takes them, and we can go from there.
On Sat, Nov 2, 2024 at 12:39 AM Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
I'll look at how you've implemented other guards and try to sing from
the same songsheet.
There's a lot of prior art, but not all of which I'd recommend. With a 15+ year code base, there are lots of things we've done/tried that I wouldn't recommend. Let's figure out how we're going to tell them apart and then we can figure out the best plan.
Also, if the radio doesn't balk at them being in the radio as TX-able even if the older firmwares refuse, that might just be the best plan. CHIRP won't tell the user they're putting in a channel they won't be able to transmit on, but not all the drivers can/do provide that feedback. This driver does, mostly because of the three (four now?) variants.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
I just dumped 65 images and created a spreadsheet describing the menu options on my radio.
Discovering .chirp/backups made this a lot easier. First, I moved the original backups out of the way and created a temporary empty backups directory. After each image dump, I just ran 'mv TID* somefilename' in the backups directory. Afterward, I moved the backups directory elsewhere and put the original backups back.
You should be able to see two files here (a PDF and a google sheet) and a subfolder with the (currently) 65 images.
https://drive.google.com/drive/folders/1BqRjX_4OElZVpYGFCnKVLLRwjUkWoMh8?usp...
There is a default image which is from uploading the original factory default image to the radio, then every other file changes only one setting from the default to a setting that is described by the name of the file. I also included the version of the online manual that I just downloaded that does not cover all of the settings (and actions; some of the menu "settings" are actually actions), but covers more of them than are currently covered in chirp. If I dump more images to get more setting information, I'll plan to add them here. I dumped some of the options that are already covered, sometimes because the name in the current menu structure doesn't exactly match the name in the menu structure and I wanted to be sure I was looking at the same thing.
I don't have any plans to delete them, but anyone should feel free to download and/or copy them at your own discretion.
In addition, I have emailed tidradio to ask for information — since they explicitly advertise chirp support for this radio on their site and in their amazon listing, it's not impossible that they'll actually want to help.
On Sat, Nov 2, 2024 at 7:16 AM Michael K Johnson mcdanlj@gmail.com wrote:
Ah, so KISS is an appropriate thing to attempt here. Since you have an earlier version to test with, I'll first plan to just implement at least some of the new settings I find, and let you tell me whether your older radio takes them, and we can go from there.
On Sat, Nov 2, 2024 at 12:39 AM Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
I'll look at how you've implemented other guards and try to sing from
the same songsheet.
There's a lot of prior art, but not all of which I'd recommend. With a 15+ year code base, there are lots of things we've done/tried that I wouldn't recommend. Let's figure out how we're going to tell them apart and then we can figure out the best plan.
Also, if the radio doesn't balk at them being in the radio as TX-able even if the older firmwares refuse, that might just be the best plan. CHIRP won't tell the user they're putting in a channel they won't be able to transmit on, but not all the drivers can/do provide that feedback. This driver does, mostly because of the three (four now?) variants.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
On Fri, Nov 1, 2024 at 11:52 PM Michael K Johnson mcdanlj@gmail.com wrote:
Your sample image in the repository starts: 00000000 50 33 31 31 38 33 ff ff ff ff ff ff ff ff ff ff |P31183..........|
My factory image, as well as every other dump I've checked that I've done, starts: 00000000 50 33 31 31 38 35 ff ff 00 00 00 00 00 00 00 00 |P31185..........|
I now understand that P31183 is the HD8, P31184 is GMRS, and P31185 is HAM.
But I have confirmed that TIDRADIO_TD-H3.img does start with P31183, I wasn't making it up. It also says "Welcome TD-H8" — So I think that your test image might actually be an H8 image?
Should I just replace it with an image from the new firmware, or do you want to do something more like have multiple versions for multiple firmware releases?
I have TX220 implemented and have successfully set the bit in my radio. Now that I understand how this works, I should be able to make fairly rapid progress on the rest of these settings.
I did see this in the TD-H3:
_tx_power = [chirp_common.PowerLevel("Low", watts=1.00), chirp_common.PowerLevel("High", watts=4.00)]
According to my manual that should be 2W and 5W respectively. Do you prefer separate commits for such things, or is it less work to do it all together?
[image: image.png] Also, I've seen mention that the firmware is upgradeable, but someone said that they only give it to you if you are in a facebook group. I'm curious about this, as not a facebook user...
But I have confirmed that TIDRADIO_TD-H3.img does start with P31183, I wasn't making it up. It also says "Welcome TD-H8" — So I think that your test image might actually be an H8 image?
It's been a while, but IIRC the early H3s basically had a firmware load from an H8 without a bunch of things changed that shouldn't be. So I suspect that image is from that era.
Should I just replace it with an image from the new firmware, or do you want to do something more like have multiple versions for multiple firmware releases?
We can't do that without separate subclasses that claim them. The (driver) tests are driven from the images. The sample images are for the tests, so whenever we add new code I like to avoid a change to an existing image as a sort of proof that the new code still works with the old image (insofar as the tests would tickle something). I don't really think we need an update to the image in the tree (unless there's a reason in which case we need to handle that case). If you really want to change it, please put it in a separate commit after and separate from any code changes.
I did see this in the TD-H3:
_tx_power = [chirp_common.PowerLevel("Low", watts=1.00), chirp_common.PowerLevel("High", watts=4.00)]According to my manual that should be 2W and 5W respectively.
This really doesn't matter. It is only used for import/copy-and-paste operations where the import logic will try to pick the closest available power level to whatever you're bringing in. It need not be absolutely correct, and lots of radios have different power levels on each band, which we don't model. We can change it, but it's just not as important as it probably seems.
Do you prefer separate commits for such things, or is it less work to do it all together?
A separate commit per logical change please. They can be in a PR together though if they're reasonably related.
--Dan
On Sat, Nov 2, 2024 at 7:12 PM Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
We can't do that without separate subclasses that claim them. The (driver) tests are driven from the images. The sample images are for the tests, so whenever we add new code I like to avoid a change to an existing image as a sort of proof that the new code still works with the old image (insofar as the tests would tickle something). I don't really think we need an update to the image in the tree (unless there's a reason in which case we need to handle that case). If you really want to change it, please put it in a separate commit after and separate from any code changes.
Yeah, I just also saw your preference to not make a whole new set of radios classes for this unless absolutely necessary. Didn't know how you wanted to balance that.
Do you prefer separate commits for such things, or is it less work to do
it all together?
A separate commit per logical change please. They can be in a PR together though if they're reasonably related.
Perfect, that's my preference as well.
Thanks for all the help today!
On Sat, Nov 2, 2024 at 7:24 PM Michael K Johnson mcdanlj@gmail.com wrote:
On Sat, Nov 2, 2024 at 7:12 PM Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
We can't do that without separate subclasses that claim them. The (driver) tests are driven from the images. The sample images are for the tests, so whenever we add new code I like to avoid a change to an existing image as a sort of proof that the new code still works with the old image (insofar as the tests would tickle something). I don't really think we need an update to the image in the tree (unless there's a reason in which case we need to handle that case). If you really want to change it, please put it in a separate commit after and separate from any code changes.
Yeah, I just also saw your preference to not make a whole new set of radios classes for this unless absolutely necessary. Didn't know how you wanted to balance that.
This turned out to be important, which won't surprise you at all.
The old firmware has an all-0xFF block 0xCA0-0xCA7 in which several new settings have been placed. One of those settings, a 4-bit setting 56.SCAN BAND, is undefined for 0xF. I have used that as a sigil for keeping all the settings in 0xCA0-0xCa7 hidden unless a defined value for scan band is found.
Making a PR now.
No matter what I try, I can neither enter nor paste an Offset or Duplex for a 1.25m repeater. Programming 1.25m repeaters was ultimately what was motivating me to do this work.
Even if I just unconditionally add 220-225Mhz to _txbands and comment out my special handling of being sensitive to the current 52.200TX setting for testing, if I type "1.6" in the Offset column or - in the Duplex column, it silently goes away without printing an error. It works fine for 2m and 70cm bands. I've looked through chirp_common.py and I haven't been enlightened. I'd love a pointer to where I could next look to fix this.
No matter what I try, I can neither enter nor paste an Offset or Duplex for a 1.25m repeater. Programming 1.25m repeaters was ultimately what was motivating me to do this work.
Even if I just unconditionally add 220-225Mhz to _txbands and comment out my special handling of being sensitive to the current 52.200TX setting for testing, if I type "1.6" in the Offset column or - in the Duplex column, it silently goes away without printing an error. It works fine for 2m and 70cm bands. I've looked through chirp_common.py and I haven't been enlightened. I'd love a pointer to where I could next look to fix this.
That'd be something in the driver. I've got a busier day today but I'll try to look at your PR tonight or tomorrow and keep an eye out for what might be going on.
--Dan
Oh, yeah, I was sure it's something in the driver. Was reading other code to try to understand what in the driver it might be, because I don't understand all the details of the interface contacts in my first day looking at it. 😅
As you have time I'll appreciate whatever attention you can provide to it. I'm sure it's something simple that I missed...
Thanks!
On Sun, Nov 3, 2024, 10:34 Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
No matter what I try, I can neither enter nor paste an Offset or Duplex
for a 1.25m repeater. Programming 1.25m repeaters was ultimately what was motivating me to do this work.
Even if I just unconditionally add 220-225Mhz to _txbands and comment
out my special handling of being sensitive to the current 52.200TX setting for testing, if I type "1.6" in the Offset column or - in the Duplex column, it silently goes away without printing an error. It works fine for 2m and 70cm bands. I've looked through chirp_common.py and I haven't been enlightened. I'd love a pointer to where I could next look to fix this.
That'd be something in the driver. I've got a busier day today but I'll try to look at your PR tonight or tomorrow and keep an eye out for what might be going on.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
I looked at this again after sleeping on it. I will have to understand when I can modify valid_bands in order to change this to honor the current setting. If they don't overlap I don't have that problem. I'll play with this now.
On Sun, Nov 3, 2024 at 12:08 PM Michael K Johnson mcdanlj@gmail.com wrote:
Oh, yeah, I was sure it's something in the driver. Was reading other code to try to understand what in the driver it might be, because I don't understand all the details of the interface contacts in my first day looking at it. 😅
As you have time I'll appreciate whatever attention you can provide to it. I'm sure it's something simple that I missed...
Thanks!
On Sun, Nov 3, 2024, 10:34 Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
No matter what I try, I can neither enter nor paste an Offset or Duplex
for a 1.25m repeater. Programming 1.25m repeaters was ultimately what was motivating me to do this work.
Even if I just unconditionally add 220-225Mhz to _txbands and comment
out my special handling of being sensitive to the current 52.200TX setting for testing, if I type "1.6" in the Offset column or - in the Duplex column, it silently goes away without printing an error. It works fine for 2m and 70cm bands. I've looked through chirp_common.py and I haven't been enlightened. I'd love a pointer to where I could next look to fix this.
That'd be something in the driver. I've got a busier day today but I'll try to look at your PR tonight or tomorrow and keep an eye out for what might be going on.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
The fix was simple and obvious after sleep, as so often happens. Sorry for the bother and noise last night!
On Sun, Nov 3, 2024 at 12:33 PM Michael K Johnson mcdanlj@gmail.com wrote:
I looked at this again after sleeping on it. I will have to understand when I can modify valid_bands in order to change this to honor the current setting. If they don't overlap I don't have that problem. I'll play with this now.
On Sun, Nov 3, 2024 at 12:08 PM Michael K Johnson mcdanlj@gmail.com wrote:
Oh, yeah, I was sure it's something in the driver. Was reading other code to try to understand what in the driver it might be, because I don't understand all the details of the interface contacts in my first day looking at it. 😅
As you have time I'll appreciate whatever attention you can provide to it. I'm sure it's something simple that I missed...
Thanks!
On Sun, Nov 3, 2024, 10:34 Dan Smith via Developers < developers@lists.chirpmyradio.com> wrote:
No matter what I try, I can neither enter nor paste an Offset or
Duplex for a 1.25m repeater. Programming 1.25m repeaters was ultimately what was motivating me to do this work.
Even if I just unconditionally add 220-225Mhz to _txbands and comment
out my special handling of being sensitive to the current 52.200TX setting for testing, if I type "1.6" in the Offset column or - in the Duplex column, it silently goes away without printing an error. It works fine for 2m and 70cm bands. I've looked through chirp_common.py and I haven't been enlightened. I'd love a pointer to where I could next look to fix this.
That'd be something in the driver. I've got a busier day today but I'll try to look at your PR tonight or tomorrow and keep an eye out for what might be going on.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com
participants (2)
-
Dan Smith -
Michael K Johnson