New Model #4933

Baofeng BF-T1 or BF-9100 or Mini 'walkie talkie'

Added by Gabe Cottrell 11 months ago. Updated 4 months ago.

Status:Closed Start date:06/21/2017
Priority:Normal Due date:
Assignee:Pavel Milanes % Done:

100%

Category:-
Target version:- Estimated time:20.00 hours
Chirp Version:daily Equipment Loan Offered:Yes

Description

I'm checking to see if there is any interest in adding the baofeng BF-T1 or BF-9100 as I've seen it described.
From most sellers its listed as a 400-420mhz or a 440-470mhz but having two of the units its SDR with a range of 400-470mhz

409shop has them, I've tried the baofeng usb programmer, with the '9100' 409shop provided, but it seems to not recognize the radio.

BaoFeng BF-T1 Read.pcap - USBPcap of a Read Operation (28.3 kB) Lance Clarke, 09/01/2017 01:33 pm

BaoFeng BF-T1 Write.pcap - USBPcap of a Write Operation (8.8 kB) Lance Clarke, 09/01/2017 01:33 pm

9100_En_Setup.exe - Programming Software (1.8 MB) Lance Clarke, 09/01/2017 01:34 pm

BaoFeng BF-T1 Read.spm (575.6 kB) Lance Clarke, 09/05/2017 10:00 am

BaoFeng BF-T1 Write.spm (73.8 kB) Lance Clarke, 09/05/2017 10:00 am

BaoFeng BF-T1 Read.txt (8 kB) Lance Clarke, 09/05/2017 10:05 am

BaoFeng BF-T1 Write.txt (8 kB) Lance Clarke, 09/05/2017 10:05 am

20161209165917020.doc - BF-T1 User Manual (775 kB) Lance Clarke, 12/06/2017 10:50 am

20161209165833185.docx (60.6 kB) Lance Clarke, 12/06/2017 11:13 am

izmenenie_razmera_ba.jpg (26.7 kB) Dmitry Milkov, 12/07/2017 09:56 am

Capture.png (89.3 kB) Lance Clarke, 12/07/2017 11:30 am

VHF-UHF.png - Frequency Capability (15.7 kB) Lance Clarke, 12/08/2017 02:07 pm

comm_logic.txt - Updated communication logics (2.1 kB) Pavel Milanes, 12/11/2017 06:00 am

test.dat - OEM channel save file to create a known compare point (18.4 kB) Pavel Milanes, 12/11/2017 06:00 am

debug.log (23.6 kB) Lance Clarke, 12/11/2017 10:35 am

Error.png (10.8 kB) Lance Clarke, 12/11/2017 10:35 am

debug.log (23.6 kB) Lance Clarke, 12/11/2017 11:04 am

debug.log (23.6 kB) Dmitry Milkov, 12/11/2017 11:11 am

Screen.mp4 (2.9 MB) Lance Clarke, 12/11/2017 11:49 am

Radio.mp4 (4 MB) Lance Clarke, 12/11/2017 11:49 am

debug.log (23.6 kB) Lance Clarke, 12/11/2017 12:57 pm

bf-t1 (hwh).py - Hank's modified version of Pavel's driver. (16.5 kB) Harold Hankins, 12/11/2017 03:54 pm

debug.log (23.6 kB) Lance Clarke, 12/11/2017 04:11 pm

Error.png (11.3 kB) Lance Clarke, 12/11/2017 04:49 pm

debug.log (22.7 kB) Lance Clarke, 12/11/2017 04:49 pm

debug.log (22.7 kB) Lance Clarke, 12/11/2017 04:54 pm

test.dat (18.4 kB) Harold Hankins, 12/11/2017 05:16 pm

test_w7hwh.img (384 Bytes) Harold Hankins, 12/11/2017 05:25 pm

screenshot_of_test_dat_in_chirp.png (71.2 kB) Harold Hankins, 12/11/2017 05:25 pm

Capture-windows.PNG (118.7 kB) Harold Hankins, 12/11/2017 05:33 pm

Error.png (10.5 kB) Lance Clarke, 12/11/2017 07:19 pm

debug.log (23.6 kB) Lance Clarke, 12/11/2017 07:19 pm

test-dat_read_debug.log - log from successful read by chirp from radio loaded with test.dat (36.1 kB) Harold Hankins, 12/11/2017 07:48 pm

Baofeng_BF-T1_20171212.img (384 Bytes) Dmitry Milkov, 12/11/2017 09:40 pm

debug.log (37.3 kB) Dmitry Milkov, 12/11/2017 09:40 pm

BF-T1.img (384 Bytes) Dmitry Milkov, 12/12/2017 08:03 am

BF-T1.dat (18.2 kB) Dmitry Milkov, 12/12/2017 08:03 am

debug.log - USB3 "bf-t1 (hwh).py" (23.5 kB) Dmitry Milkov, 12/12/2017 09:22 am

debug.log (23.6 kB) Lance Clarke, 12/12/2017 10:23 am

bf-t1 (hwh).py (16.5 kB) Lance Clarke, 12/12/2017 10:23 am

Settings 1.png (30.2 kB) Lance Clarke, 12/12/2017 11:19 am

Settings 2.png (57.6 kB) Lance Clarke, 12/12/2017 11:19 am

debug_004.log (23.6 kB) Dmitry Milkov, 12/12/2017 11:35 am

debug_005.log (36.9 kB) Dmitry Milkov, 12/12/2017 11:35 am

debug_006.log (36.9 kB) Dmitry Milkov, 12/12/2017 11:35 am

test_1.dat (18.2 kB) Dmitry Milkov, 12/12/2017 12:14 pm

test_1.img (384 Bytes) Dmitry Milkov, 12/12/2017 12:14 pm

bf-t1.py - Latest version, Channels freq + offset + wide + upload. (17.6 kB) Pavel Milanes, 12/12/2017 01:29 pm

changes_hwh - change to make write succeed (933 Bytes) Harold Hankins, 12/12/2017 02:38 pm

bf-t1_hwh2.py - Pavel's version with the my changes (17.6 kB) Harold Hankins, 12/12/2017 02:38 pm

debug.log (23.6 kB) Lance Clarke, 12/12/2017 03:10 pm

change_hwh3 - changes to fix windows (175 Bytes) Harold Hankins, 12/12/2017 03:57 pm

bf-t1_hwh3.py - a version of the driver Pavel posted 2 hours ago with hwh changes included (17.6 kB) Harold Hankins, 12/12/2017 03:57 pm

debug.log (37.6 kB) Lance Clarke, 12/12/2017 10:32 pm

debug_bf-t1.py.log (39.5 kB) Dmitry Milkov, 12/12/2017 11:31 pm

debug_bf-t1_hwh2.py.log (46.2 kB) Dmitry Milkov, 12/12/2017 11:31 pm

debug_bf-t1_hwh3.py.log (46.2 kB) Dmitry Milkov, 12/12/2017 11:31 pm

changes_against_latest - changes to make write work (290 Bytes) Harold Hankins, 12/13/2017 08:01 am

bf-t1.py - Latest version, test this one. (20.1 kB) Pavel Milanes, 12/13/2017 08:41 am

version_code - code to find firmware version. (294 Bytes) Harold Hankins, 12/13/2017 04:24 pm

Baofeng_BF-T1_full_eeprom.log - debug.log of full eeprom read (66.6 kB) Harold Hankins, 12/14/2017 03:55 pm

Baofeng_BF-T1_full_eeprom.img - img of full eeprom read (2 kB) Harold Hankins, 12/14/2017 03:55 pm

my-bf-t1.py - experimental settings tab added , basic settings (25.9 kB) Henk Groningen, 12/16/2017 02:32 am

my-bf-t1.py (21.7 kB) Henk Groningen, 12/16/2017 08:13 am

volume.jpg (97.6 kB) Henk Groningen, 12/16/2017 12:09 pm

bf-t1.py - Latest driver with settings to test/validate (28.1 kB) Pavel Milanes, 12/18/2017 07:40 am

settings.JPG (20.6 kB) Emiel v, 12/18/2017 10:12 am

settings-screenshot.png (54.3 kB) Harold Hankins, 12/18/2017 10:29 am

Image 1.png (27.4 kB) Dmitry Milkov, 12/18/2017 11:02 am

Browser.JPG (131.2 kB) Emiel v, 12/18/2017 01:14 pm

test.py (26.3 kB) Henk Groningen, 12/18/2017 01:32 pm

2.img (2 kB) Emiel v, 12/18/2017 02:56 pm

1.img (384 Bytes) Emiel v, 12/18/2017 02:57 pm

fixed_setting.png (19.5 kB) Harold Hankins, 12/18/2017 03:40 pm

CQN-bf-t1.py (28.2 kB) Henk Groningen, 12/20/2017 12:05 am

dmitry.py (28.4 kB) Henk Groningen, 12/20/2017 05:18 am

bf-t1.py - Finas driver, this is the one sent to the devel queue for inclusion in next Chirp. (28.6 kB) Pavel Milanes, 12/21/2017 02:47 pm


Related issues

related to Bug #5439: Error Downloading BF-T1 per Test Protocol Closed 12/11/2017

Associated revisions

Revision 2942:6c867670a555
Added by Pavel Milanes 5 months ago

[New Model] Add support for the Baofeng BF-T1, fixes #4933

Add support for the Baofeng BF-T1, also known as BF MINI
or BF-9100.

Complete support for:
- Channels
- Special Channels
- Settings

73 Pavel CO7WT.

Revision 2944:d7387ba19a90
Added by Pavel Milanes 5 months ago

[PATCH] Fix FM settings and bad channel 0, fix #4933

Users find that FM settings does not apply the decimal point.

Wrong offset in channel listing, causing a bogus channel zero to show.

73 Pavel

Revision 2945:16dc67ee13d1
Added by Pavel Milanes 5 months ago

[PATCH][Baofeng BF-T1] FM callback correction, fixes #4933

Last patch introduced a bug in the FM callback, this one fix it.

History

Updated by Gabe Cottrell 11 months ago

Going back over it again, I was able to get the "9100" software to run and program the radio, it also can run in the 136-174mhz as well I have it receiving KIH-35 on 162.5500, and I need to check it for transmit on when I get to one of my MURS radios.

Updated by Lance Clarke 9 months ago

I can offer a radio for development as soon as the one I ordered gets here from China.

Updated by D L Col 9 months ago

I would love to be able to use CHIRP on this radio.

Updated by Lance Clarke 9 months ago

I just received one of these. It is a Dual Band HT, covering VHF: 136-174MHz and UHF: 400-470MHz.

How can we get it added to CHIRP?

Updated by Lance Clarke 9 months ago

I can provide WireShark captures of Read and Write operations if that would help.

Updated by Lance Clarke 9 months ago

And here is a working copy of the programming software.

Updated by Lance Clarke 9 months ago

Serial Port Monitor files.

Updated by Lance Clarke 9 months ago

Ascii files

Updated by David Rowell 7 months ago

Just adding my support for adding this lovely little unit to CHIRP. And many thanks for uploading the 9100 software. I bought the programming software for the unit from Banggood, but couldn't get any of it to work! The 9100 works fine, but it would be great to bring the capability into CHIRP.

Updated by Dmitry Milkov 7 months ago

Thanks for uploading the 9100 software. The 9100 works fine, but it would be great to bring the capability into CHIRP.

Updated by Marcus Jenkins 6 months ago

+1 for chirp support for Baofeng 9100 / T1 Mini. 73, EA5IGC

Updated by Ivan Hazelton 6 months ago

Willing to donated BF-T1/BF-9100A and/or lend same plus BF-Mini for inclusion in CHIRP.

Updated by Pavel Milanes 6 months ago

  • Equipment Loan Offered changed from No to Yes

Hi,

I Will love to accept the radio to develop a driver in my winter vacations (December/January).

I have some experience with the BTECH radios as I'm one of the developers that bring them to Chirp, but, Huston... we have a problem: I live in Cuba island, and you can not simply "ship" a radio via special(DHL)/regular mail to Cuba.

Custom laws are loosen here by now, all it needs is a person that bring the radios to Camagüey Cuba (my home town) and put it on custody of the custom authorities for me up on entrance; Then I can later pick it up at and start developing a driver for Chirp.

It's not as hard as it sound, the main problem is to find a person that came to Cuba to bring the radio.

I'm all ears to any proposal, I'm in fact stuck in developing for Chirp for months now, as I don't have any new radio at hand to hack and support.

Cheers, Pavel CO7WT.

Updated by Pavel Milanes 6 months ago

Wow...

I wrote my comment without actually "see" the BAOFENG BF-T1 radio (google search) it can even pass as a toy walky-talky radio by any custom check point in the world... hi hi hi...

I'm looking the files uploaded and the protocol and memory layout is really trivial compared to the UV-5R and the BTECHS.

Does any of you a link for the user manual that can pass it to me/paste here?

Cheers, Pavel CO7WT.

Updated by Lance Clarke 6 months ago

You can find the manual here: http://www.baofengradio.com/UploadFiles/20161209165833185.docx

I'm also attaching it to this post.

HTH

Updated by Lance Clarke 6 months ago

Sorry, that last one was the manual in Chinese. Here is the English version: http://www.baofengradio.com/UploadFiles/20161209165833185.docx

Updated by Pavel Milanes 6 months ago

  • Status changed from New to In Progress
  • Assignee set to Pavel Milanes
  • Estimated time set to 20.00
  • Chirp Version changed from 0.4.0 to daily

Got them.

I will try to came up with a dev driver to test as soon as possible...

I don't see any baudrate indication at a glance, can any of you tell what is the exact baudrate and codification the driver uses? 8N1, 8E2, etc?

Stay tuned!

73 Pavel, CO7WT

Updated by Lance Clarke 6 months ago

It's 9600 8N1, but the UART is in the cable. You don't need a driver for the radio. The cable uses the same driver as all my other Baofeng and TYT cables.

Updated by Harold Hankins 6 months ago

To be clear, the programming cable is not the one that comes with the radio, that one is a charge only cable. The actual programming cable is available separately and contains a prolific pl2303 usb-serial chip.

Updated by Pavel Milanes 6 months ago

  • % Done changed from 0 to 10

Good to know Dimitry!

Thanks, I will start coding this weekend on the base of the docs/infos I have from this thread...

I have taken responsibility of this issue by now, but as I don't have a radio to test I need of all of the users to test the code.

Next week I must have a dev driver to test.

73 Pavel, CO7WT.

Updated by Lance Clarke 6 months ago

I am happy to assist with any testing.

Updated by Dmitry Milkov 6 months ago

Hi guys!
Thank you!
I'm ready to test the program.
Link to the instruction in English.
http://www.radioscanner.ru/files/download/file20279/baofeng_bf-t1_-_users_manual.pdf

Link to the list of channels.
http://www.radioscanner.ru/files/download/file20094/bf-t1-zavodskie.zip
Open in the programming Software 9100_En_Setup.exe

Topic in forum (in Russian)
http://lpd.radioscanner.ru/topic26647.html

Updated by Lance Clarke 6 months ago

Okay, I opened the list and see this. Is this what you wanted?

Updated by Pavel Milanes 6 months ago

  • File comm_logic.txt added
  • % Done changed from 10 to 30

Hi,

Last night I put some time into de task, attached is a file with a description of the comm logic extracted from the attached files.

I have a rudimentary driver that must be capable of at least downloading the eeprom, I will try to improve it and do a basic channel mapping with the info I have at hand.

Thanks to Dimitri for the links and picture of the list of channels, with that I can speculate about a few points:

  • Eeprom save from the 9100 file is greater than the 0x1700, so this leads to think abut a zone of more data or settings, hard to tell at this point. Compatibility with the mobile versions? more channels & features from one version to another?
  • Total Eeprom save from 9100 software is 0x48b4 = 18612 bytes (18.612 Kbytes)
  • The end of the segment of the data in the OEM software as a string like this "137 174 400 470" so this may be VHF capable or shared with the mobile version of the radio, which is good. Also there are some freqs at config like places?

UPDATE: The file saved from the OEM Software is not an eeprom image, so last statement is not entirely true.

As I have enrolled into developing a driver for Chirp in a "remote" way in the past (BTECTs) I must say that I will need a radio in my hands to test and validate all the features, otherwise the support will be only experimental and with just basic channel handling from my side.

That if no other developer take the lead of my work and continue to support it.

Expect some news on Monday.

73 Pavel CO7WT.

Updated by Lance Clarke 6 months ago

this may be VHF capable

Yes, the radio IS VHF capable. They don't advertise it as such though, because the VHF performance is poor. I have used it on VHF successfully over about 1/4 mile.

!!

Updated by Pavel Milanes 5 months ago

Hi to all.

Attached to this post is a dev driver that must be capable of downloading the radio data just as the OEM software does; I have tried to do a simple channel interpretation and validation, so this is prof of concept driver to test PC <> radio communication.

No modify or upload is enabled at this point, you will get an error if you doit.

How to test it?

  1. Download the attached file named bf-t1.py to your desktop.
  2. Start Chirp and go to Help menu and tick "Enable Developer Functions"
  3. Go to File menu and select a new option named "Load Module" and select the file you just downloaded to your desktop (Now your chirp has the new test driver incorporated until you close it)
  4. Try to download from the radio as usual, you will find a Baofeng BF-T1 listed.
  5. If all goes well and you get a channel listing please save that image for reference.
  6. DO NOT ATTEMPT to change/modify/upload the data, this is just a prof of concept driver.
  7. If it doesn't work please go to this chirp wiki page: https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues there you will learn how to find your chirp log and please attach it here for later revision.

Now if this prof of concept driver worked and you see some of your channel data; please do the following.

  1. Save your channel data with the OEM software.
  2. Download the file attached to this post named test.dat and open it with the OEM software.
  3. Program the data crafted by me using the OEM software to the radio.
  4. Use Chirp then to download the data from radio (follow the above procedure) once it worked just save a chirp radio image
  5. Name the file test_yourcall.img and upload it to this post.

With the data on that chirp save I can reverse engineer the downloaded data and make more accurate channel properties interpretation.

I have updated the comm_logic.txt file with some other details after another round of revision of the data provided and OEM software poking.

The main issue appears to be that the OEM software is just reading the relevant (to it) memory part, the radio can have a bigger mem map that we are detecting.

If you are brave and want help me out to really understand this radio, do the above procedure and load in Chirp the bf-t1_mem_explore.py file attached to this post

Then do a download of the radio data, don't worry if chirp makes an error, in fact we are poking the radio to see how big is the real mem space, an error and his details will be logged on chirp's log, and that's what we want.

Once the download has ended (with error or not) please save the chirp collected data to a file named test_mem_yourcall.bin and attach it to this post; also please locate the chirp log of that session and attach it also, the log is as important as the image file.

Again, with no radio at hand I can do this tests by myself, so I need you to make it and collect all the data for me, you may notice that i urged to included the callsigns of the users in the files, yes, the more the data I get the more accurate we can craft a chirp's driver.

73 Pavel CO7WT.

Updated by Pavel Milanes 5 months ago

  • File deleted (comm_logic.txt)

Updated by Dmitry Milkov 5 months ago

Hello Pavel!
Do you speak Russian?
I could not open the module bf-t1.py
Windows10 x64 chirp-daily-20171204
Error

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added
  • File bf-t1_mem_explore.py added

Hi, Lance reported in another bug #5439 about an error.

The error was about a timeout being too small.

Attached to this post are the two files updated with a bigger timeout. (I will erase the old ones to avoid confusions)

73 Pavel CO7WT.

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1_mem_explore.py)

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Dmitry Milkov 5 months ago

The new file does not work. The same error.

Updated by Lance Clarke 5 months ago

My error was different this time. Files attached.

Updated by Pavel Milanes 5 months ago

Dmitry Milkov wrote:

Hello Pavel!
Do you speak Russian?
I could not open the module bf-t1.py
Windows10 x64 chirp-daily-20171204
Error

Hello Dimitry.

Sadly no, beside my Russian originated name I can only do a "slight" read in Russian as I received a few lessons here in the school in Cuba at a very young age; but then they switched to teach english. It was in the 90' when the URSS fall apart... you know the background.

Only Spanish (Mother language) and English as acquired one here.

About the error you are getting, don't worry it's a common mistake: you need to open the link and then click on download to get the real .py file.

If you do a right click & then save over the link, you get a html page saved as a .py and hence the error. Try to open it on a separate window and click the download link.

I will be in front of the PC connected to the internet for about an hour from now, if you do it now I can get it to work it at night, if not I will get it tomorrow... I have Internet only in public WIFI parks, not at home.

73 Pavel CO7WT.

Updated by Pavel Milanes 5 months ago

Lance Clarke wrote:

My error was different this time. Files attached.

Error but PROGRESS !!!

We have a validated and identified radio successfuly.

The radio refused (or don't has time) to respond to the query for the eeprom data...

I'm reviewing the pcap files to see if I missed something...

Keep an eye on this, we have make the first step.

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

Please let me know if there is anything else I can do to help.

Thanks for everything you're doing!

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added

Ok, from the pcap file and from the serial logs I can not see any distinct step from what we are doing.

Some radios are touchy with the timeouts, from the ident step to the data transfer there is no apparent wait that the actual timeout does not covers.

Let's try to increase the timeout in the data transfer, please try the attached driver and report back the log and comments.

Updated by Lance Clarke 5 months ago

Same error. Log attached.

Updated by Pavel Milanes 5 months ago

This are the problems that the users don't see in the development process... fine tuning the vars and timeouts.

I would like to see if any other user has this problem...

Dimitri can you test it?

I will take a deep dive in the serial logs once again to see if I missed something.

73 Pavel CO7WT

Updated by Dmitry Milkov 5 months ago


Updated by Pavel Milanes 5 months ago

Ok, this is a strange error.

As per the pcap USB serial log and the serial log attached to this thread I can't identify any different from what we are doing now.

I would ask a few questions to get an idea of what to expect.

  1. With the OEM software the radio does reboot or makes any strange behavior in the reading process?
  2. Does the read process with the OEM software run smoothly? (no appreciable stop or pause in the progress bar or the entire read process)
  3. Can any of you produce a short video of the download process with the OEM software showing both the radio and the PC screen for me? (a youtube link will be enough, no need to upload it here)

Thanks in advance for your comments.

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

1. My reads quickly and smoothly. It takes 2-3 seconds then the radio reboots when done.
2. Yes, very quickly and smoothly.
3. I cannot, no. Sorry.

Updated by Lance Clarke 5 months ago

Here's the best I can do. Hope they help.

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added

Thanks for the videos.

There is not a strange behavior in them thanks for our time.

Please try this... it has a more precise serial protocol setup with a little DTR handshake I found in the Eltima serial monitor log. It does not make sense if the DTR line is not connected, but worth a try.

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added

Deleted old dev drivers, and uploaded a new one from the last one, It had some python2 only arguments, fixed for compatibility with python 2 & 3.

Please report any issues/logs.

73 Pavel CO7WT

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1_mem_explore.py)

Updated by Pavel Milanes 5 months ago

Deleted the mem explore example, it has not reason to be until we have a full featured comm with the radio.

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

Still seeing the same error.

Updated by Pavel Milanes 5 months ago

Thanks for the test Lance.

Without a radio to test in my hands I'm really just stalled here. I have a few test in my mind but all of them will be just to slow and painful to make with this asynchronous schema.

I'm placing a note on the developer list to bring a few pairs of fresh eyes to this issue (and possibly a developer with one of this radios).

Will take a new look this night at home and will report back tomorrow.

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

Do you use TeamViewer? You could take control of my PC remotely and do what ever you need to do.

Updated by Tom M 5 months ago

It would be great if we had Chirp support for BF-T1. Especially that I am not sure if it is safe to install Baofeng software (i.e. 9100_En_Setup.exe). VirusTotal shows 2 trojans (hard to say if it is false-positive):

I would be happy to help with testing, but I have ordered programming cable today, so it will take some time until I receive it.

Updated by Pavel Milanes 5 months ago

Lance Clarke wrote:

Do you use TeamViewer? You could take control of my PC remotely and do what ever you need to do.

Good Idea...

Drop me and email, click on my name on any of my posts to get the details.

73 Pavel CO7WT

Updated by Harold Hankins 5 months ago

Pavel,

Your earlier version works for me to read without errors with one change:

diff --git a/bf-t1.py b/bf-t1.py
index 72c7969..063e0f0 100644
--- a/bf-t1.py
+++ b/bf-t1.py
@ -150,7 +150,7 @ def _recv(radio, addr):

  1. header validation
    - c, a, l = struct.unpack(">BHB", block[0:3])
    + c, a, l = struct.unpack(">cHB", block[0:4])

It reads the entire thing without errors and the screen shows the correct frequencies but I think a lot of the other data is wrong (tones, narrow FM, wide FM, etc).

I've attached my modified version of your file. It's a modification of the one before you started messing with DTR. I'm running it on linux.

Updated by Pavel Milanes 5 months ago

Thanks Harold, that proves that a fresh pair of eyes always see more... hi hi hi...

Dimitri & Lance, can you test the procedure described with this driver?

Harold: yes, channel data can be wrong, I was only testing the communication between radio and PC, now with a save from chirp of the data in the test.dat I can start to reverse engineer the mem layout.

Please can you do the procedure described here https://chirp.danplanet.com/issues/4933#note-27 for me and attach the chirp image file?

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

I tried using bf-t1 (hwh).py but got the same error as before.

Updated by Pavel Milanes 5 months ago

Tom M wrote:

It would be great if we had Chirp support for BF-T1. Especially that I am not sure if it is safe to install Baofeng software (i.e. 9100_En_Setup.exe). VirusTotal shows 2 trojans (hard to say if it is false-positive):

I would be happy to help with testing, but I have ordered programming cable today, so it will take some time until I receive it.

At least the copy on this issue thread is virus safe, check this link: https://www.virustotal.com/#/url/f8323802df0958c905f4f509c43cee4f84208e0878340560eaa7f1afd7d68c84/details

It appears that you get an infected copy some here...

Cheers

Updated by Pavel Milanes 5 months ago

Lance Clarke wrote:

I tried using bf-t1 (hwh).py but got the same error as before.

Are we facing driver/OS/Python issues here?

It works on linux but not in Windows? (Dimitry and lance are working on WinVista/7 with python 2.7) Harold on Linux.

Hum...

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added
  • % Done changed from 30 to 50

I'm thinking out of the box after reviewing the videos and making some math here...

Lance try this driver please...

73 Pavel CO7WT

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Pavel Milanes 5 months ago

I'm thinking out of the box after reviewing the videos and making some math here...

Please test this - fast as hell driver - driver... https://chirp.danplanet.com/attachments/3917/bf-t1.py

73 Pavel CO7WT

Updated by Harold Hankins 5 months ago

Pavel,

The fast version doesn't like the cHB format in make_frame.
File "/home/hwh/Desktop/t1-driver/bf-t1 (pavel-fast).py", line 126, in _make_frame
frame = struct.pack(">cHB", ord(cmd), addr, BLOCK_SIZE)
error: char format require string of length 1

I suspect ord doesn't return a char but I'm not really great with python.

On the other things, if I load test.dat into the 9100 oem software I'm using it doesn't error but nothing on the screen changes, it still shows the setup and frequencies I already had programmed. The about on the software I'm using says "9100 Program software, 1.3, 9100. I don't remember where it came from, I've been using it for a couple of months.

Updated by Lance Clarke 5 months ago

Using second to last, different error now.

Will try the Fast as Hell driver now...

Updated by Lance Clarke 5 months ago

Here's the Fast as Hell Error Log.

Also, I saw the same issue with test.dat that Harold described.

Updated by Harold Hankins 5 months ago

Test.dat looks like it was hand generated. It's using the non-US comma as the decimal point in the frequencies instead of using a period. Since it's a comma delimited file that appears to be confusing the program. All the files I saved with the program use periods. I'm hand changing it to periods to test it, give me a few minutes.

Updated by Lance Clarke 5 months ago

Ah, yes. I did a global replace of ",00000" with ".00000" and that seems to have fixed it.

Updated by Harold Hankins 5 months ago

The corrected test.dat is attached.

Updated by Harold Hankins 5 months ago

And finally I've caught up. This is the chirp image of the fixed test.dat saved by the version of the chirp driver I posted. And a screen capture of chirp with it loaded :^)

Updated by Harold Hankins 5 months ago

To have it all in one place this is a capture of the oem software with the test.dat I usedloaded.

Updated by Lance Clarke 5 months ago

Harold,

What driver file are you using?

Updated by Harold Hankins 5 months ago

The one I posted in https://chirp.danplanet.com/issues/4933#note-58 It works on linux, I don't have chirp loaded on windows currently to test it there.

Updated by Lance Clarke 5 months ago

Ah, thanks. I still get an error with that one in Windows 7 x64.

Updated by Harold Hankins 5 months ago

Lance,

I looked at your log, it doesn't make any sense to me. It's talking to the radio enough to put it in program mode and read the radio id string but times out after it doesn't respond to the read command in 3 seconds. I looked in my log from a successful read and it consistently takes about 40 ms to respond so if your radio doesn't respond in 3 seconds it's never going to. For anyone interested I've attached a log from a successful read run.

Tomorrow I'll load chirp on the tiny 9" windows laptop I've been using for the oem software and run a few tests and see what I can find.

Updated by Lance Clarke 5 months ago

Harold,

Please let me know if there is anything I can do to help.

Updated by Dmitry Milkov 5 months ago

Hello everybody!
It worked!
https://chirp.danplanet.com/issues/4933#note-58
bf-t1 (hwh).py
Windows7 x64

Updated by Pavel Milanes 5 months ago

Hi everybody, good morning.

I have read all the posts, we have a working driver then. I have collected all the data and will be back as soon with a more accurate driver (for the channel data)

I saw the difference in the data that Dimitry highlighted, that's why I need the img that correspond to the .dat from the OEM, to check this little details and fix it.

I noted also the >B/>c from Harold as the , by . substitution.

I will work on that issues an will be back ASAP. Thanks four your time and test.

73 Pavel CO7WT.

Updated by Dmitry Milkov 5 months ago

Hi All!
On my computer (Windows10 x64) does not work CHIRP in USB3. An error.
In USB2 everything works.
I read the data in CHIRP and the OEM program. Here is the result.
BF-T1.img = BF-T1.dat

Updated by Harold Hankins 5 months ago

Dmitry,

I wonder if Lance's problem is related to your USB3 problem. What error does it give you on USB3?

Updated by Dmitry Milkov 5 months ago

Harold,
USB3 "bf-t1 (hwh).py": CHIRP not working.
OEM soft working.
Error

USB2 "bf-t1 (hwh).py": CHIRP working. OEM soft working.

Updated by Harold Hankins 5 months ago

Thanks Dmitry, that is identical to Lance's problem, the error in his logs is the same as your log. It can read the radio id but times out and fails when it tries to read the memory.

Lance, have you tried different USB ports? Maybe the port you're using is the problem.

Updated by Lance Clarke 5 months ago

I'm using n old Dell E4310 laptop which just has 2 USB 2.0 ports. Both work fine with the OEM software as well as with CHIRP for numerous other radios.

I do have a USB 3.0 PCI card so I just tried those ports too. They work with the OEM software but not with the CHIRP driver for the BF-T1. Same error. Log attached.

Are we sure there is only one version of bf-t1 (hwh).py? I'll attach the one I'm using too. Perhaps someone can confirm it works elsewhere.

Updated by Dmitry Milkov 5 months ago

Lance,
Your file is working!
I have the same file.
MD5: 3781bdd4587eb1d87b7026fc2bbe96e7

It works on my three computers.
Laptop with Windows XP sp3
PC with Windows 7 x64
PC with Windows 10 x64

Updated by Lance Clarke 5 months ago

Dmitry,

Thanks for checking. I don't know... I guess I am just out of luck on this one.

Updated by Harold Hankins 5 months ago

Lance,

You're not alone, I just tried all three usb ports on a win10/64 laptop and get the same error. Since it consistently doesn't work for me I may be able to figure out why. On another open source project (LibrePilot) we had something similar where something related to USB serial ports worked on linux/mac but not on windows.

Updated by Pavel Milanes 5 months ago

Hi OMs, can any of you make a test for me?

The task is to find the sweet spot for the timeout value.

Please remove or comment the line #267:

radio.pipe.timeout = 3   # 3 seconds.

And then try to download the image from the radio, if you get in trouble just increase the vale on the line #42:

STIMEOUT = 1

Then even if the STIMEOUT is nice, try to get it to the real sweet spot by lowering it in discrete steps until you receive and error, then step up to a higher working value...

Once you get this value on one Operating System (Linux Mint?), please try it on other (Windows 10?) tweaking it if needed.

As per the serial logs I think that the real value for the timeout must lay in the range of 0.04 to 0.2 but without a radio at hand is difficult for me to try that.

Please report back the value to include it in the final value.

I'm working on the channel data now.

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

Perhaps we can confirm my serial port settings. I've attached a couple of screen captures.

Also, I just noticed something I hadn't before. When I click the button to start the read process, the radio reboots almost immediately. It's not sending data because it's rebooting.

Updated by Pavel Milanes 5 months ago

Also, I have progress in the channel data identification but I'm lacking some vital data.

Can any of you make and post a .dat (OEM) file and the corresponding .img (chirp) for this use cases:

  1. A channel with a tx split below the RX (example: RX 145.170 TX 144.570) No tone set.
  2. A channel with a tx split above the RX (example: RX 443.500 TX 449.500) No tone set.
  3. A pair of channels programed as simplex (no split) where the only difference is the Wide/Narrow bandwidth (Same freq, no tone)
  4. A pair of channels programed as simplex (no split) with the same DIGITAL tone on RX/TX but different in the polarity (one D###N and the other D###I, no matter what ### if it's the same on both)
  5. A pair of channels programed as simplex (no tone) where the only difference is the Scan (one ON the other OFF)

Thanks in advance for your cooperation.

This test are needed to find what combinations of bits are each setting.

73 Pavel CO7WT.

Updated by Dmitry Milkov 5 months ago

STIMEOUT = 0.04 - error
STIMEOUT = 0.05 - Not stable. Reading is not always.
STIMEOUT = 0.06 - ОК

Updated by Pavel Milanes 5 months ago

Dmitry Milkov wrote:

STIMEOUT = 0.04 - error
STIMEOUT = 0.05 - Not stable. Reading is not always.
STIMEOUT = 0.06 - ОК

Roger, thanks for the test, will set it 0.07 to be safe.

73 Pavel CO7WT.

Updated by Dmitry Milkov 5 months ago

Lance,
I have the same settings. But I have another adapter.
I do not work Prolific on Win10 with BF-T1.

Updated by Lance Clarke 5 months ago

How are you using a different UART? I'm using the Baofeng cable that came with the radio.

I just tried on a second PC and with a second radio and I see exactly the same behavior. It reboots as soon as I click to read it.

Updated by Dmitry Milkov 5 months ago

Pavel,

Updated by Dmitry Milkov 5 months ago

Lance Clarke wrote:

How are you using a different UART? I'm using the Baofeng cable that came with the radio.

https://chirp.danplanet.com/issues/4933#note-20

Updated by Pavel Milanes 5 months ago

Dmitry Milkov wrote:

Pavel,

Thank Dmitry, perfect timing... I'm working with the files you uploaded now...

Cheers Pavel.

Updated by Pavel Milanes 5 months ago

Hi to all.

Here is the latest dev version, it's based on the working code modified by Harold (W7HWH), a list of working features by now:

  1. Correct channel frequency and offset (value and direction, keep reading)
  2. Correct wide/narrow interpretation.
  3. Upload capable version.

This version has the upload feature enabled: Try to download within chirp and then without modifying anything do a upload, please report either failure & success (debug.log please)

Just modify and upload the data if you completed the above mentioned download/upload with no change and you succeed on it.

Road map from here:

  1. Complete the split function (different bands in RX/TX, for now you will see only a +/- aprox. 300 Mhz offset)
  2. Process the scan ON/OFF
  3. Process the tone data.

Once this are in place (a day or two from now, depending on my free time) we will have full compatibility with the channel data.

Then just remains the settings data... that is more difficult (slow & tedious) but doable in a remote way.

I will concentrate in make it full channel data compatible and then move to the settings part.

Cheers, 73 Pavel, CO7WT.

Updated by Harold Hankins 5 months ago

Pavel,

That last version reads but has errors writing. I went through and corrected errors until it would go all the way through write. I haven't had a chance to compare all the settings after a read/write but at a glance the screen looks the same after a read, write, read sequence. I've attached a list of the changes and a copy of your post with the changes in it.

Updated by Lance Clarke 5 months ago

Neither of the new drivers work for me but the radio reboots quicker now. So it fails faster.

Other than Dmitry's custom cable, is this working for anyone else with Windows 7 and the standard Baofeng cable?

Updated by Harold Hankins 5 months ago

Lance,

They weren't intended to change anything for the windows problem. The changes in this one make it work on my win10/64 laptop. Try it.

Pavel,

I looked at the windows problem and it looks like every time we change the radio.pipe.timeout windows either resets or does a close/open on the port. This reboots the radio taking it out of programming mode and making it not respond. Removing the radio.pipe.timeout changes in clean_buffer() makes it work on my windows laptop. It doesn't seem to make any difference on linux. Attached are the changes and a driver with these and my earlier changes included. For me it both reads and writes on both linux and windows.

Updated by Harold Hankins 5 months ago

I just tested and the changes in my previous post also work on a win7/32 laptop that wouldn't run the earlier versions. Hopefully this will fix it for all windows.

Updated by Lance Clarke 5 months ago

YAY!

Yes, this worked for reading the radio.

Updated by Dmitry Milkov 5 months ago

Pavel Milanes wrote:

Hi to all.

Here is the latest dev version, it's based on the working code modified by Harold (W7HWH), a list of working features by now:

  1. Correct channel frequency and offset (value and direction, keep reading)
  2. Correct wide/narrow interpretation.
  3. Upload capable version.

bf-t1.py Downloading works. Uploading does not work. Error.
bf-t1_hwh2.py Downloading works. Uploading works.
bf-t1_hwh3.py Downloading works. Uploading works.

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added
  • % Done changed from 50 to 90

Ok, thanks for the test, comments and the discovery of the issue with the change in the timeout, I will notice the dev team to get them aware of this possible problem in windows.

Attached to this post is the latest dev driver, including the changes from bf-t1_hwh3.py, some comments and features included:

  1. Full channel data handling (Freq, split, band-split, tones, scan skip, etc.)
  2. Download/Upload ready + fix from last findings about windows resetting the port on serial timeout change
  3. Chirp testbed passed with honors, so it's ready for inclusion on Main Chirp.

Please test it extensively and report back any bugs/failures/comments to include in chirp.

No settings by now, to process the settings I must have a radio at hand, the test are 100% try and error and each setting has different levels of configuration, so it will take a time and making it remotely is not an option.

I suggest to make a crowdfunding campaign to buy one of this radios and send it to me by DHL (there is no other sure way to get it to me, don't dare to send it by regular mail) and ship it as a toy walky talky.

For the cost of the radio and shipping must be not a big deal if you get at least 10 users involved. Just an idea.

73 Pavel CO7WT.

Updated by Pavel Milanes 5 months ago

A question.

Can any of you please clarify the use of the Emergent and Relay CH ?

In he programming schema, channel 0 is the Emergent CH and the Relay CH is not processed yet.

I'm asking to decide the best way to handle this two "special" channels.

73 Pavel CO7WT.

Updated by Harold Hankins 5 months ago

Pavel,

The changes from post #100 need to be implemented to make write work. The hwh3 driver version included them but it's change list was just for the change from hwh2 to hwh3. Against your latest post the changes are in the attached file.

Updated by Pavel Milanes 5 months ago

Thanks, updating it and will post it ASAP

Updated by Pavel Milanes 5 months ago

He it is.

Latest with Harold fixes, please test and report back.

73 Pavel CO7WT

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Pavel Milanes 5 months ago

  • File deleted (bf-t1.py)

Updated by Lance Clarke 5 months ago

Pavel,

My offer of using TeamViewer still stands, if that would help you work on the settings.

Updated by Harold Hankins 5 months ago

Pavel,

The one you posted an hour ago works to both read and write. :^)

I tested it on both linux and win10/64.

Updated by Pavel Milanes 5 months ago

Harold Hankins wrote:

Pavel,

The one you posted an hour ago works to both read and write. :^)

I tested it on both linux and win10/64.

Ok, I will wait for Lance and Dmitry testing before send it to Chirp in an official way.

Good news: A ham contact me by mail and he is working to ship one of this radios to me, full support is on his way people.

Thanks to this generous ham.

73 Pavel CO7WT.

Updated by Dmitry Milkov 5 months ago

Hi to all.
I tested the last file bf-t1.py. Reading and writing work. All OK. Win10 x64

Pavel Milanes wrote:

A question.

Can any of you please clarify the use of the Emergent and Relay CH ?

The radio has a separate button SOS. It the Emergent.

In he programming schema, channel 0 is the Emergent CH and the Relay CH is not processed yet.

It is right. I think so.

Relay CH - I do not understand why.

Updated by Harold Hankins 5 months ago

I suspect the "relay" channel has something to do with the mobile (car) radio the T1 was designed to work with. If you look at the picture of the back of it on Banggood's Car/T1 Page it shows a relay connector on the back.

I just placed an order for the last one they had in stock to check and see if I can learn more. They're quoting 8-10 days delivery but I expect it will take longer because of Christmas mail.

Updated by Pavel Milanes 5 months ago

Hi to all.

I was searching the net to now better the two special CH in this radio and found that the BF-T1 (also known as BF-9100) is suspiciously similar to the BF-9200 (http://www.baofengradio.com/enProShowcn.asp?ID=364) they has almost the same description/features.

Maybe this driver also work with that one?

73 Pavel CO7WT

Updated by Lance Clarke 5 months ago

Pavel Milanes wrote:

Ok, I will wait for Lance and Dmitry testing before send it to Chirp in an official way.

It's working great for me now!

Updated by Harold Hankins 5 months ago

Pavel,

It's not really useful for Chirp but I think I found the firmware version. I'd guess it's June 8, 2016. The silkscreen on the board says Jan 24, 2016 so that would be reasonable. I've attached where to find it in case it's useful sometime.

[2017-12-13 19:16:11,027] chirp.ui.mainapp - INFO: Version '16.06.08 BF9100S'

Updated by Henk Groningen 5 months ago

Hi Pavel,

Great work.
Tested it and so far so good. Worked out some of the settings, only the ones you can change from the menu on the radio.
this is the unknown016 array in settings. ====
byte 2 = squelch d0-d9
byte 3 = vox d0-d9
byte 4 = tx timer, d0 is off, d1-d6 time in 30 sec increments
byte 5 = multi setting register in binary form
backlight = bit1-bit0 > 00 =off, 01 = key, 10 = on
squelch tail = bit5 > 0 = off, 1 = on
busy lockout = bit4 > 0 off, 1 = on
key beep = bit3 > 0 off, 1 on
byte 6 = scan type, d0 = timed, d1 = carrier, d2 = stop
byte 9 = alarm ( count down timer ) d0 - d16 in half hour increments
byte 10 = voice prompt, d0 = off, d1 = english, d2 = chinese
byte 14 = relay mode, d0 = off, d2=re-tx,d1=re-rx ( but how it works?) ====

Other settings may follow, but 9100.exe.crashes on my main workstation.

regars

Henk

Updated by Pavel Milanes 5 months ago

Harold Hankins wrote:

Pavel,

It's not really useful for Chirp but I think I found the firmware version. I'd guess it's June 8, 2016. The silkscreen on the board says Jan 24, 2016 so that would be reasonable. I've attached where to find it in case it's useful sometime.

[2017-12-13 19:16:11,027] chirp.ui.mainapp - INFO: Version '16.06.08 BF9100S'

Hi Harold,

0x06F0... hum...

Have you made a test to determine how big is the real firmware?

I'm interested in a .img of the entire size for the radio, can you made one and post it?

There are yet some issues with the fingerprint (I have used a "apparently" free space in a special location, but that's just a patch) and maybe we can improve that with a real full image.

A generous ham agreed to send me one of these radios next week, I hope it get to my hands by the end of the year or beginning of next one. But it's very interesting to see and try to reverse engineer the full image.

BTW, I have pushed the patch for this radio to the developer queue, it's time now for review and approval, so if all goes well we will have it in main Chirp for xmas. (Just channel support)

73 Pavel CO7WT.

Updated by Pavel Milanes 5 months ago

Henk Groningen wrote:

Hi Pavel,

Great work.
Tested it and so far so good. Worked out some of the settings, only the ones you can change from the menu on the radio.
this is the unknown016 array in settings.
[....]
Other settings may follow, but 9100.exe.crashes on my main workstation.

regars

Henk

Hi Henk,

Thanks for the compliments, but they are not for me alone, the users of this thread are the main actors, I am only the conductor of the orchestra...

Just now you become a new player, thanks for the info, I will implement and validate that settings ASAP.

73 Pavel CO7WT.

Updated by Harold Hankins 5 months ago

Pavel,

The t1 has a 2k eeprom. I'm away from computer all day but I'll post full dump tonight.

Updated by Henk Groningen 5 months ago

Pavel Milanes wrote:

Thanks for the compliments, but they are not for me alone, the users of this thread are the main actors, I am only the conductor of the orchestra...

I do aknowledge everyones contribution, but still .. a master-conductor.

Anyway, some more settings for the unknown0 array:

--
byte 5
bit 2 keylock 0=off,1=on ( still changable from set when set on)
bit 7 battery save 0=off, 1=on
bit 6 fm-radio 0=off, 1=on ( off disables fm button on set )
byte 7 active channel, d1-d20, setting it works on upload
byte 8 , fm range , 1=low 65-76, 0=high 76-108
byte 11, volume d1-d7
( set to #FF by original software on upload, chirp uploads actual value so no max vol after prgm )
byte 15 tx pwr, 0 = low, 1 = high
---

This should cover all settings available through the original software.
byte 13 changes after an upoad from the 9100 software, not discovered what it means/does, yet.
There are other unused bytes in the array, but don't want to brick mine just now .. had it for two days.
Setting the relay-frequency in the browser and uploading seems to work too, even whithout shift. So seems to be just a normal channel without any specific use, as is the emergency channel. As for that channel: it seems to be a dual watch function, with emergency-reception overriding normal reception.

73 Henk PA3CQN

Updated by Henk Groningen 5 months ago

addition on byte 13:

byte 12 and 13 are the frequency of the fm receiver.
2 byte value, resulting frequency is 65 + value*0.1 MHz.
With byte 12/13 as #145 that would be 65 + 325*0.1 = 97.5 MHz

73 Henk PA3CQN

Updated by Harold Hankins 5 months ago

Pavel Milanes wrote:

0x06F0... hum...

Have you made a test to determine how big is the real firmware?

I'm interested in a .img of the entire size for the radio, can you made one and post it?

Pavel,

The physical eeprom is a K24C16, a 2k x 8 bit serial eeprom. I've attached both a log and img file of the full eeprom. A lot of it is just 0xFF but there are a few areas that have other things.

Updated by Harold Hankins 5 months ago

Pavel,

That doesn't actually include the true firmware, the read command only reads the configuration eeprom. If you try to read past 2k it just wraps around and gives you starting over at the beginning.

There's probably another command we don't know to read/update the actual cpu firmware. The cpu is a Fujitsu MB95F013K and I haven't found a manual on it yet to see if I can find a way to read it.

Updated by Henk Groningen 5 months ago

Pavel, hope you don't mind ...

Since I was eager to get chirp working on my main machine ( 9100.exe throws an exception ) I gave working with py script a go.
Based on your script and the example UV-B5 script on the site I tried to make sense of it all, editing the script in notepad++ ( grh, what is that with the indentation in notepad++ ).
Anyhow: I got a basic working settings tab. FM frequency and radio-limits are still missing, but all basic settings are there and seem to work.

Updated by Henk Groningen 5 months ago

small update, had to take into account that the original 9100.exe sets volume to 255.
so anyone with an original img that still had volume as 255 would not see the settings tab.

Updated by Lance Clarke 5 months ago

Is it possible to expose the volume setting on the Settings Tab? I find it annoying that the volume always resets to the MAX any time you write to the radio.

Or if not expose it, at least have it maintain the user's current setting.

Updated by Henk Groningen 5 months ago

Lance Clarke wrote:

Is it possible to expose the volume setting on the Settings Tab? I find it annoying that the volume always resets to the MAX any time you write to the radio.

Or if not expose it, at least have it maintain the user's current setting.

Lance,

It does on my version. You do need the second version I uploaded( that copes with the annoying max volume ).
I have no idea how to add inline images here, but it is the fifth option, using chirp daily-20171204.
And chirp keeps the volume.

I guess you are not seeing the volume? But you are seeing the settings tab?

73 Henk PA3CQN

Updated by Lance Clarke 5 months ago

Henk Groningen wrote:

Lance,

It does on my version. You do need the second version I uploaded( that copes with the annoying max volume ).
I have no idea how to add inline images here, but it is the fifth option, using chirp daily-20171204.
And chirp keeps the volume.

I guess you are not seeing the volume? But you are seeing the settings tab?

73 Henk PA3CQN

Great! I haven't had a chance to try your version yet but I hope to later today.

Thanks!

Updated by Lance Clarke 5 months ago

Henk Groningen wrote:

Lance,

It does on my version.

Henk,

It's working great!

Thanks to all of you for your work.

Updated by Henk Groningen 5 months ago

Pavel, Dmitry, Harold, and yourself did the real work!
I will try and extend the settings with the fm_vfo. As for the band limits, I'm leaving that to someone else. I don't see the added value on a fixed frequency handheld.

It's a fun little radio to play with, and supprisingly sensitive on the reception side of things.
Ok, the headset is crap and not even working, and I do recommand the volume mod.
But for the 12 euro's I paid to get it delivered to the Netherlands it was money well spend.

Now the search for other hidden settings can begin. There must be some ..

Updated by Pavel Milanes 5 months ago

Wow.

I get away for a while and miss a few things.

Harold and others, I have a full settings version working at home, I'm on my cell now, my version has all the validation un place, including the volumen bug, It has a small bug detected by the Chirp testbed.

I will work It tonigth and tomorrow Will publish the full versión.

Sorry for the typos, my cell force the spanish.

73 Pavel CO7WT

Updated by Henk Groningen 5 months ago

Pavel Milanes wrote:

Wow.

I get away for a while and miss a few things.

Harold and others, I have a full settings version working at home, I'm on my cell now, my version has all the validation un place, > including the volumen bug

Yeah, I skipped most validations since the only way to get wrong values is by setting them in the chirp browser.

fiy:
- you can set the fm vfo to any value from 65-108 at any time in software. The limits are only there for tuning on the bf-t1 itself
- the exact workings of the relay channel remain a mystery: however, it does function like any other channel. I programmed it through the settings browser, and it just works, regardless of tx/rx sync setting. The synchronisation indeed is for the 9100, but why? The BF-T1 sends out channel information on channel change, so the mobile set would be synchronized anyway.

Updated by Pavel Milanes 5 months ago

Hi to all.

Sorry for the delay, I'm on vacations with my family until January and kids and wife has its own agenda. ;)

Attached is the latest driver, with all the settings validated and ready to go to chirp for inclusion, just remains the users "smoke test" on real hardware.

Some points to considerate/comment:

  1. WARNING: starting with this version I changed the file size of the .img to be the full eeprom on download and just the channel data on upload, so your old saved .img files will not work anymore. This is a must do step to get a good and reliable image fingerprint for chirp.
  2. I'm open for suggestions about how to handle the Relay Channel, the logic dictates to handle it as a regular channel. The "relay" action is not very clear yet, any thoughts?. (I have to work it yet, as it uses a separate mem space from the main channels, and I'm yet scratching my head about how to mix it with the main mem space as this is a "rare avis", I'm looking on other Chirp's drivers for a precedent like this)
  3. I have arranged the settings in two categories: Basic and FM Radio, but we can split them in more categories as the basic is a long list to my appreciation, may be adding an "Advanced" category? (VHF/UHF Limits and ...)
  4. What items would you move to the "Advanced" Settings Category?
  5. FM Radio Issues: Henk pointed that you can set in chirp the radio to any freq even outside the declared FM Range, Should I restrict and force the FM preset station to the range specified in the settings?
  6. If we leave it in the actual form then there is no need/logic to show/handle the selected FM range... what do you think about this?

Please comment about the above points, test the driver and report back any success/fail stories.

Just after your positive comments and work on any new issue or correction I will send it to the dev queue.

73 Pavel CO7WT.

Updated by Emiel v 5 months ago

Dear Pavel; thanks for your work!
Memory reading seems to be ok; but "setting" shows an empty space.
The previous "my" file did show "basic" setting options.
73, Emiel

Updated by Harold Hankins 5 months ago

It works fine on my 3 T1 radios.

Updated by Henk Groningen 5 months ago

Hi Pavel,

Nice work.
For my personal likings:
- I would leave the FM as is, without check, but it does not really matter to me
- I would remove the limits settings, they do not add anything of value as you cannot change the frequency on the set.
Or at least move them to an advanced tab, they now clutter the settings tab. Of course they should be internally used to validate input for channels, but there is no need for the user to change them.
- I would set both emergency and relay channel to special channels. I looked at the setup from a UV-B5 this morning where vfo1 and vfo0 are special channels and it is not that difficult. If you download the UV-B5.py and search for 'SPECIALS' it will be easy to copy.
- the column polarity for DTCS is a questionmark. Has anyone tested if the set really can do that? It is not in the original software.
- the column cross mode is not really needed. But that is a CHIRP thing I guess. It confused me for quite a while since it is based on the settings from RX/TX tone modes, and not a setting itself. Same for tone-mode. Again this follows from RX/TX settings. But again, this is something in CHIRP.
- the prompt in the py file could be adjusted, it still says 'settings' is not available.
- I have nothing against Harold, but perhaps the credits for exploring the settings and initial work there could be set to me :)

There is one complaint: your original py took 2.5 seconds to download the memory. The latest one takes 9.5 seconds. Did you increase some timeout ?

73 Henk PA3CQN

Updated by Dmitry Milkov 5 months ago

Harold Hankins wrote:

It works fine on my 3 T1 radios.

+1

Updated by Henk Groningen 5 months ago

E. van Puffelen wrote:

Dear Pavel; thanks for your work!
Memory reading seems to be ok; but "setting" shows an empty space.
The previous "my" file did show "basic" setting options.
73, Emiel

Emiel, works ok here too. What version of chirp are you using?

Updated by Harold Hankins 5 months ago

Henk Groningen wrote:

- I have nothing against Harold, but perhaps the credits for exploring the settings and initial work there could be set to me :)

I hadn't noticed those comments with my name. I'd agree the second mention (around line 396) should be you.

Updated by Henk Groningen 5 months ago

Harold Hankins wrote:

Henk Groningen wrote:

- I have nothing against Harold, but perhaps the credits for exploring the settings and initial work there could be set to me :)

I hadn't noticed those comments with my name. I'd agree the second mention (around line 396) should be you.

TNX..

By the way: did you ( or Dmitry )notice an increase in download time? Or is it just me?

Updated by Harold Hankins 5 months ago

I just timed it, from hitting OK until the download completes takes about 6 seconds for me.

The original driver took 2.5 seconds because it was only downloading the first 386 bytes of the eeprom. The current one downloads the full 2048 bytes in the eeprom to get the version/model info that's near the end of the eeprom.

Updated by Henk Groningen 5 months ago

Yep, discovered it in line 40.
Hmm, there is certainly an advantage in correctly identifying the device. But there is also an advantage in speed ...
But programming is a once in a time event, so not really a big thing

Updated by Emiel v 5 months ago

CHIRP daily-20171204 (latest) here on win 10 64.
The previous file my-bf-t1.py did work ok!

Updated by Emiel v 5 months ago

Maybe it is something very specific for my computer... best to ignore as so many other have no problems

Updated by Emiel v 5 months ago

with bf-t1.py: memories and Browser tabs (see file) work! ... just Settings doesn't show information

Updated by Harold Hankins 5 months ago

Emiel,

Maybe some setting in your radio is a problem for the settings tab.

Try reading from the radio, saving the img on your hard drive, and then posting it here. I'll load the image into one of my radios and see if it has the same problem.

Updated by Henk Groningen 5 months ago

E. van Puffelen wrote:

CHIRP daily-20171204 (latest) here on win 10 64.
The previous file my-bf-t1.py did work ok!

Strange, both files are nearly identical.
It works for all testers.
Just out of curiousity: could you try test.py ?

Updated by Emiel v 5 months ago

test.py works good! including Settings Basic and FM radio; first 1.img was made with this file;

2.img was made with bf-t1.py (chirp did not show settings)

Updated by Emiel v 5 months ago

Updated by Harold Hankins 5 months ago

Emiel,

You have an invalid setting in the file, the normal 470MHz upper limit is set to 480MHz.

Use the browser to change uhfh to 470 as in the attached, save the file, and then open it again. That should make it work.

Updated by Wookhyun Shin 5 months ago

Thank you for your work!
When I export/import .csv file using bf-t1.py in #138, it raises 'List index out of exception'.

Can you check?

Updated by Dmitry Milkov 5 months ago

Wookhyun Shin,
Export/import .csv file works for me.
Perhaps the following will help:
Remove all settings the program. Delete file chirp.config in "%APPDATA%\CHIRP"

Updated by Henk Groningen 5 months ago

Harold Hankins wrote:

Emiel,

You have an invalid setting in the file, the normal 470MHz upper limit is set to 480MHz.

Use the browser to change uhfh to 470 as in the attached, save the file, and then open it again. That should make it work.

That is indeed the problem. test.py which I uploaded does not include the bandlimit settings, thats why it works for Emiel. I
suspected the problem to be in that setting, since it is the only fundamental difference with Pavel's version.

Updated by Wookhyun Shin 5 months ago

Dmitry Milkov
Thank you. I've removed all settings but it didn't solve the problem.

I figured out rToneFreq, cToneFreq was empty when I exported the settings.
After I update the values using GUI it didn't happen again.

Updated by Henk Groningen 5 months ago

Pavel,

Sorry but ran into a major problem: tuning steps.
In the memory table you cannot enter values like 430.237500, that is 6.25 kHz steps. The BF-T1 itself rounds to 5 kHz and 6.25 kHz steps.
Somehow when you enter a value in the table it is checked against valid steps, and by failing to find them rounds to 5 kHz steps. If you right click and select properties you can enter 6.25 steps. Could not find a quick solution.
In the UVB5 py there is an array UVB5_steps , but a simular BFT1_steps array in BF-T1.py does not work.
Do you know how to solve this?

73 Henk PA3CQN

Updated by Emiel v 5 months ago

Dear all,

Yes... after setting upper UHF to 470 the settings tabs works now with bf-t1.py

The 9100 software allows 130-174 and 400-520. so setting upper UHF to 520 in Chirp will solve all problems users (like me!) can cause by doing this. There are many reasons why it is better not to use these higher limits; in practice many persons will try it. like to find out extended receive options.

Thanks for adding BF-T1. This Chirp version is already far superior to the 9100 program. Like cutting and pasting channels from a generic file to the BF-T1 is really nice!

Updated by Henk Groningen 5 months ago

Pavel, disregard my previous complaint about the frequency. On my laptop it works ok.
So must be my fault, perhaps damaged image or something like that.
Strange, can't explain it. But false alarm, sorry.

Updated by Emiel v 5 months ago

Is it possible to add an option set the bandwidth for "FM" (broadcast) to narrow (NFM)? Would be nice for 70 MHz/4m. Or is it a separate fixed, wide receiver?

Updated by Emiel v 5 months ago

Emiel v.P. wrote:

Is it possible to add an option to set the bandwidth for "FM" (broadcast) to narrow (NFM)? Would be nice for 70 MHz/4m! Or is it a separate fixed, wide receiver?

Updated by Henk Groningen 5 months ago

Hi all,

I've made an update to Pavel's excellent version by setting the relay and emergency channels as 'special' channels.
It is more in line with excisting Baofeng drivers. Do not forget to click 'special channels' in the UI to see them.
I also moved the bandlimits to a seperate tab in settings, as they are less frequently used.

73 Henk, PA3CQN

Updated by Dmitry Milkov 5 months ago

Henk,
Excellent!
You need to change the Band limits to 130-174 and 400-520.
The 9100 software allows you to do this!
Thank you.

Updated by Henk Groningen 5 months ago

Dmitry,

Bandlimits and Baofeng has been a longstanding debate. Most likely, like my UV-B5, it can even be set to extend into 220 on VHF ( yep, confirmed ! but very poor performance ), smack in the middel of EU DAB+.
But .. the endstage is not designed to cope with this extended range, and spurious ( not that good to start with ) is gigantic.
So the question is: do we allow responsible persons ( e.g. HAM operators ;-) ) to receive outside of the standard limits, or do we restrict
the limits for the more casual user?
I am inclined to remove the bandlimits setting alltogether. It is still possible to set the limits through the browser, but at least that is a bit more complicated.

Updated by Henk Groningen 5 months ago

Dmitry

Compromise! This one has a trick:
- in the settings browser set either VHFH of UHFH to a value above the normal limit, e.g. UHFH to 480.
- save and than close the image
- re-open the image, the limits tab now supports higher values.

Remember: if you set both VHFH and UHFH on or below the standard limits and save the file you have to do this trick again.

Updated by Dmitry Milkov 5 months ago

Henk,
Thank you. But. I use standard frequencies.
I wanted to chirp all the possibilities of the OEM software.
I am sorry for my English.

Updated by Henk Groningen 5 months ago

Dmitry,

Yeah, it's just a bit of fun to build-in an easter-egg. Only couple of lines.
Maybe Pavel will keep it, maybe not. I's up to him, as is the choice to keep the special channels solution.

I would not use it out of limits, 70 cm is what I bought it for, and I'm allowed to use. And maybe sometimes with 0.5 W on PMR, semi-legal. Like I said, it doesn't really function well outside the limits, and with prolonged use may will damage the set.

Anyway, has been fun tinkering with the driver. Never used Python before, and only had the excisting py files to work it out. Nice brain-teaser.

73 Henk PA3CQN

Updated by Pavel Milanes 5 months ago

Hi to all.

I'm away but informed via mail, I'm integrating all the suggestions and comments and also the special channels hack from Henk, I will come back tomorrow with a final driver and also a patch for support on chirp for the developers queue.

Thanks to all for helping me to bring another radio to chirp.

I think it's mature enough to go now to he main chirp.

73 Pavel CO7WT

Updated by Pavel Milanes 5 months ago

  • File bf-t1.py added
  • % Done changed from 90 to 100

Hi to all.

Could not resist to make it today... beside the children ran off with their grandpas... so I get some free time.

Attached is the latest driver with all the new features discussed and fully Chirp testbed compilant. I will set the completion to 100%, as a patch to the developer queue has ben sent for inclusion.

It has been a great journey, and a fun project (as always) even when I don't have the radio at hand, this is a beautiful example of what we can achieve when we work together, as a community, count on me for other radios, even remotely ones like this.

If the users contribute we can make it, there is no need to has the radio on hand for models as simple as this, if we have active and dedicated users that contribute to make it possible, the prof is the BTECH driver that covers a lot of variations on the same core drivers (and started remotely when it was a small project, now is a huge project wonderfully maintained by Jim Unroe) and now this one.

On the other side, for more complicated radios and more fast developments having the radio at hand is a must. As Dan posted some time:

Developers Works for Radios!

If you can ship it to me via DHL I will bring it to Chirp ASAP.

Now only remains the developers review and inclusion on the next chirp release.

Cheers and Merry Xmas and a Happy New Year for all.

73 Pavel CO7WT.

Updated by Lance Clarke 5 months ago

Thank you Pavel.

Updated by Dmitry Milkov 5 months ago

Hello everybody.
Pavel, is this a mistake?
This is bf-t1.py - Finas driver, this is the one sent to the devel queue for inclusion in next Chirp. (28,56 КБ) Pavel Milanes, 22.12.2017 01:47

Updated by Henk Groningen 5 months ago

simple solution

533 rf.memory_bounds = (0, self._upper)

should be

533 rf.memory_bounds = (1, self._upper)

Updated by Pavel Milanes 5 months ago

Thanks for the detail, I will check It, 73

Updated by Lance Clarke 5 months ago

There may be an issue setting the FM frequency. Steps to duplicate:

  1. Download the current code plug
  2. Navigate to Settings -> FM Radio
  3. In the FM Station box, enter: 97.1
  4. Upload the code plug

View the FM frequency on the radio or download the code plug and you will see the FM frequency was written as 97.000

If you instead enter 97.100 it will store correctly, but I don't think you should have to append the trailing zeros.

Updated by Pavel Milanes 5 months ago

Lance Clarke wrote:

There may be an issue setting the FM frequency. Steps to duplicate:

  1. Download the current code plug
  2. Navigate to Settings -> FM Radio
  3. In the FM Station box, enter: 97.1
  4. Upload the code plug

View the FM frequency on the radio or download the code plug and you will see the FM frequency was written as 97.000

If you instead enter 97.100 it will store correctly, but I don't think you should have to append the trailing zeros.

Will check, tks

Updated by Henk Groningen 5 months ago

Pavel,Lance

I think this will solve it:

def apply_fm_freq(setting, obj):
setattr(obj, setting.get_name(),
int(setting.value.get_value()*10) - 650)

Updated by Pavel Milanes 5 months ago

Support for this Radio has been included on the main Chirp.

Also a patch for last bugs (Channel Zero and FM decimal) has ben sent to the dev queue, so wait for a fix in the forthcoming days.

Have a Happy New Year to all.

73 Pavel CO7WT.

Updated by Henk Groningen 5 months ago

Nice work all, and esp. Pavel for starting this effort.
Pavel, I hope the set donated to you will arrive soon.
It's just a fun set to play with despite it's size.

73 Henk PA3CQN

Updated by Henk Groningen 5 months ago

Pavel,

Sorry but there is still a small error in the fm-callback

line 833:

int(setting.get_value() * 10) - 650)

should be

int(setting.value.get_value() * 10) - 650)

Updated by Pavel Milanes 5 months ago

Hi to all.

I confirmed the Henk notice on the bug I introduced, sorry. I will patch it ASAP.

HNY to all.

73 Pavel CO7WT.

Updated by Pavel Milanes 5 months ago

  • Status changed from In Progress to Resolved

I'm tagging this issue as resolved, and if no more bugs are found in a few days I will Close it.

The last patch was applied just a minute ago.

Please if you found a bug,after the issue closure (in a few days) place a new issue tagged as a bug report.

Thanks to all for your contribution & help.

73 Pavel CO7WT.

Updated by Henk Groningen 5 months ago

Hi Pavel / All,

Had not been reading this for a couple of days after a serious crash ( fried uP/MB/PS ).
Seems all is working fine now. I agree this issue can be closed.
Has been a nice project to be part off, and contribute to.

Now it's time to investigate the hidden stuff ..

73 Henk PA3CQN

Updated by Pavel Milanes 4 months ago

  • Status changed from Resolved to Closed

This item is closed, new bugs about the BF-T1 must be opened in a new bug report.

73 Pavel CO7WT.

Also available in: Atom PDF