CHIRP

Rob Zak wrote in #note-1:

Cam Cornelius wrote:

Hello,

Marcus Dudley has been developing an amazing firmware for the Tidradio TD-H3. The FW is new from the ground up and currently only works with his basic programmer. Currently he is not interested in a pluging for CHIRP, but the community is. This is a fairly new firmware (still in release candidate mode), but very polished and robust with much better features and flexibility than Tidradio's stock firmware. The FB group for this firmware already has almost 8 thousand members in under 4 months.

He has published the file format and serial protocol on his website here: https://nicsure.co.uk/h3h8/forumdisplay.php?fid=8

The facebook group is here: https://www.facebook.com/groups/456942886822492

I'm not a programmer, but just wanted to make you aware. Any traction on this would be greatly appreciated.

Thank you,
Cam Cornelius
K1CAM

I am NOT a programmer! Using ChatGPT I cam up with a SHELL for a driver. I'm sure someone smarter than me can use this to make it work. It was created by using the links posted by Cam and the example.py from CHIRP.

I too want to see a working driver, so I'm only trying to give it a kick start.

Thanks, Rob. Unfortunately the module isn't loading in the latest CHIRP-Next.I get an "Invalid or unsupported module file" error.

EDIT: Just saw your note...thanks for the head start!

Rob, thanks for the effort, but that GPT-generated "driver" doesn't even resemble a CHIRP driver. The template driver in the CHIRP tree (which does nothing other than load) is much closer. If you don't mind, I'd please ask you to delete it from the attachments here because people will try it, and will contact the team and open other bugs complaining that the one in this bug does not work. I appreciate the intent, but since it's not really a better start than the template driver, it will only serve to confuse users and cause extra paperwork for the team. Thanks for understanding.

Dan Smith wrote in #note-4:

Rob, thanks for the effort, but that GPT-generated "driver" doesn't even resemble a CHIRP driver. The template driver in the CHIRP tree (which does nothing other than load) is much closer. If you don't mind, I'd please ask you to delete it from the attachments here because people will try it, and will contact the team and open other bugs complaining that the one in this bug does not work. I appreciate the intent, but since it's not really a better start than the template driver, it will only serve to confuse users and cause extra paperwork for the team. Thanks for understanding.

Dan, I can appreciate where you're coming from with the comment. I can't figure out how to delete it, or I would happily comply. I realize it won't load, I tried to be clear this doesn't work. I thought the read/write commands were correct, as well as the data structure. I'm sorry. Let me know how to remove and I surely will.

No worries, I just removed it.

Nope, none of that stuff did anything to actually talk to the radio. It was pretty typical gen-AI hallucination about all the details that were too obscure to find on google :)

Thanks anyway!

Dan Smith wrote in #note-7:

No worries, I just removed it.

Nope, none of that stuff did anything to actually talk to the radio. It was pretty typical gen-AI hallucination about all the details that were too obscure to find on google :)

Thanks anyway!

Thanks Dan, again, apologies for the distraction. Perhaps you'd be willing to take a look at creating a functional driver? Thank you.

Agreed. Any help with a driver would be appreciated, Dan.

Thanks and looking forward,
Cam

On Mon, Nov 4, 2024 at 9:10 AM Rob Zak redmine@chirpmyradio.com wrote:

The Developers page has a link to the github repo and the guidelines for submission. You can submit a PR there when you're ready for review.

Gonzalo Torró wrote in #note-10:

Here I send a initial work for the NicFw. The driver is able to read and write most of the stuff. The only thing I couldn't get to work is modifying the steps. Somehow I generating the right block to the radio (since the other stuff is correctly uploaded) but I have to investigate further. Subtones are not yet implemented.

This was my first try on implementing a driver in CHIRP so I probably did many mistakes.

I see that Marcus documented the eeprom map now, and has stated that he intends to keep it stable, which makes it a reasonable chirp target.

https://nicsure.co.uk/h3h8/showthread.php?tid=53

Since I recently worked on updating the driver for the stock TD-H3 and am now interested in this firmware, let me know if you need any help.

I am also interested in seeing the 'nicsure FW' version of the TD-H3 available in Chirp. I am willing to send anybody a nicsureFW-programmed TD-H3 radio if they commit to writing the Chirp programmer for it.

-Damon (K9CQB)

Damon Schaefer wrote in #note-13:

I am also interested in seeing the 'nicsure FW' version of the TD-H3 available in Chirp. I am willing to send anybody a nicsureFW-programmed TD-H3 radio if they commit to writing the Chirp programmer for it.

I am not committing, and don't need more TD-H3s, but I am starting with what Gonzalo Torró wrote and am adding additional settings to it as nicsure has currently documented, and will work on it as I have time available. I wanted to wait first to see whether he wanted to keep going first, but if I make meaningful progress I'll either upload a new copy here if it's not quite ready, or if it looks done, I'll happily PR it with a test image. Gonzalo, please speak up if you have cares here! ☺

While I'm not committing, since I run Linux and have put nicFW on my TD-H3, I'm highly likely to carry this through.

(Incidentally, I'm curious whether the TD-H8 nicFW will be mostly settings-compatible with the TD-H3 nicFW. At least the interpretation of power will be different because 255 is 5W on the TD-H3 and the H8 won't be limited to 5W... I've asked on the forum.)

I asked about H3 vs H8 eeprom layouts, and Marcus said:

Both firmwares are based on the same core code so the locations and general layout of things will likely not change, but due to the differences in the radio chip there will be some things that exist in the H3 and do not in the H8 and vice versa.

As a result, it will probably be even easier than the stock firmware to have one driver for both radios with NicFW.

As much as I love Chirp and what it provides the community, I find it difficult to understand how developing a Chirp module makes sense. nicFW has been, and will continue to be a moving target for as long as Marcus decides. And he has made it clear that he is only developing for himself, not the community. Even the tagged Version 1.0 is already being left behind. It would be about impossible for a developer to keep up with this and continue to provide a working version of Chirp for the Tidradio nicFW H3.

Jeff Widgren wrote in #note-16:

As much as I love Chirp and what it provides the community, I find it difficult to understand how developing a Chirp module makes sense...

Marcus has made it clear in https://nicsure.co.uk/h3h8/showthread.php?tid=53 cited above that he does not intend to change existing eeprom setting definitions, just add new ones. Given that he's actually documented them (vs. Tidradio who advertise chirp support but don't document their settings), I think your argument doesn't hold a lot of water.

I haven't had a lot of time yet to do more relative to Gonzalo's work than update the settings to cover everything so far that Marcus has (as of a few weeks ago) documented, and I still need to do a few experiments with some actual firmware dumps to make sure I understand what things are little-endian (it wasn't obvious to me from Gonzalo's work), so it's not like I have a lot invested here.

I am a member of his forum but do not use Facebook, so I'm not a member of the Facebook group for his firmware. He has definitely been engaging with forum members over new features there, and I have not seen there that he has "made it clear that he is only developing for himself, not the community" [citation needed].

WRT keeping up: As long as the eeprom values don't change incompatibly, we're better off tracking NicFW than stock, because Marcus documents his eeprom values and Tidradio doesn't. Therefore, your argument about it being hard to keep up applies better to Tidradio stock than to NicFW. It's not a great argument there either, since it took me just a few hours to go from not knowing chirp to working out all the new settings they had added since the initial TD-H8-based support and getting the driver updated.

I'm not sure why you would try to talk folks out of attempting to support NicFW in chirp. What skin is it off your teeth if someone does? What you wrote reads like you are carrying a chip on your shoulder towards Marcus. If you don't like him or his firmware, please go use stock and the stock driver that I and others have contributed to, and ignore this issue that won't affect you in any way one way or another.

I'm much happier using NicFW than stock on my TD-H3, and as a Linux user it's a right pain for me to go get a Windows machine to program it, so every time I want to program it I'll have a reminder that this is something I'd like to do some day. ☺

I appreciate your feedback, and I now have a better understanding that having the eeprom logic can lower the impact on keeping Chirp working with nicFW. I really enjoy the nicFW project and firmware. I've still got it installed on my H3.

You noted [citation needed]. There are 9 published common user mistakes that Marcus posted... I was referring to number 7:

7 Entitlement. nicFW was not written for you, it was written for me. It reflects the way I feel a radio should operate. I simply make the firmware available for others to use if they wish. Some people make the mistake of believing that I am catering for others, I am not, I'm catering for myself. If someone makes a suggestion I feel would be useful for me now or in the future, I will implement it, if it then proves useful to others then that's just a bonus. Using nicFW does not entitle you to anything nor does it obligate me to do what you want. If you want to make a suggestion and specify the potential benefits, go ahead, but if you word it in such as way as to be effectively saying "this is how it SHOULD work", you will not be well received. I can see through the pretense and passive-aggressive nature of such posts instantly even if others cannot.*

Thank you for the citation!

There, it is very important to note the context. The first word of what you quoted is is "Entitlement" and he is referencing behavior where people think that they are entitled to tell him what to do.

Here's more context: https://nicsure.co.uk/h3h8/showthread.php?tid=71

nicFW is an advanced firmware meant for advanced users and pioneers.

Marcus is doing this for his own pleasure, and implementing what interests him, and rationally dislikes people telling him what they think he should do. At the same time, he expects "advanced users and pioneers" to be people who would appreciate some of the same things he does; see his "meant for" in that statement. I have seen on his forum that he has appreciated thoughtful users, including those sharing new ideas without implying that he is obligated towards them.

I have not seem the nine common user mistakes posted on his forum, so it might be that he has found it more necessary to push back against bad behavior on Facebook than on his own forum.

If he ever does make a wholesale revision to the eeprom layout in some new version some day, say because of running out of room and needing to revisit it, that wouldn't be that hard to handle in the code. Creating a new memory layout and conditionalizing bits of code that work with only one layout or the other seems likely to be easy. I conditionalized some of the stock tidradio functionality on whether they had meaningful data in a certain location in the settings; this wouldn't be particularly different. It might be automatic based on some information, or it might show up as a variant in the menus, depending on what he did. But either way it would fit naturally with other chirp drivers, as far as I can tell.

It sounds like there has been some progress on the TD-H3 CHIRP driver supporting nicFW firmware. I assume this is for the new v2? It is unclear from the comments. I don't see any WIP PR in GitHub. If Michael Johnson or Gonzalo Torro want help testing this I'm happy to do so. No experience with CHIRP drivers, but 20+ years of professional Python experience, so point me to some code and I can probably take it from there (offer is to test/refine, not to try and take over this effort from others).

In case it is helpful to others, Gonzalo's GH repo for the updated driver is here:

https://github.com/EA5JQP/chirp_driver_Tidradio_H3_NicFW

At the time of this writing it partially works (read & write to TD-H3 with nicFW v2.07.06). See the issue I posted about what doesn't work (briefly: cut-and-paste, and ability to add new channels):

https://github.com/EA5JQP/chirp_driver_Tidradio_H3_NicFW/issues/1

I went through the docs to add all the documented configuration at the time into the MEM_FORMAT, but have been so busy lately that time to take a few hours to do dumps to validate endianness (not specified in the docs) has been hard to come by.

I note that Marcus appears to have shut the forum down in favor of Github. The forum just says that it is closed until further notice, but https://github.com/nicsure/nicfw2docs seems to have replaced the docs on the forum. Firmware builds are still available at https://nicsure.co.uk/h3/nightly.php

I just now saw https://github.com/nicsure/nicfw2docs/blob/main/eeprom.md which says

All multi-byte values are LITTLE-Endian for V2.0X codeplugs. All multi-byte values are BIG-Endian for V2.5X codeplugs.

Not sure what the "V2.5X" codeplugs are since I don't see a V2.5 on the nightly build page. Might end up wanting to have a base memory format string with placeholder text for multi-byte fields and use replacement on the string for different values? Or maybe he's just referring to on-disk format from the official programmer?

If anyone wants to take a crack at validating my MEM_FORMAT the usual way of "download, change one settings, download again" and looking at the changes in developer mode in chirp, please don't hesitate to reach out. I don't want to get in the way of anyone else working on this. I still can't imagine continuing to use this firmware and not eventually adding this, though! Having to run under Wine to program the radio is annoying. ☺

Ian, I had never touched chirp before I updated the stock TD-H3 support last fall, but also have lots of Python experience, so if you'd like to work on this, I'll happily send you my WIP to play with! I just didn't want to post it here without validating at least endianness! ☺

I sent my WIP. What I had worked on was just the memory layout; I hadn't created any UI or logic around it.

There's no point as far as I can tell in supporting old versions. But if there is because the 2.0x versions are maintained indefinitely, we can deal with that separately.

73 de KZ4LY