Project

General

Profile

Actions

New Model #3227

closed

HYT TM-800V support

Added by Pavel Milanes almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
01/26/2016
Due date:
% Done:

0%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:

Description

This is a relatively new radio introduced in Cuba as a Commercial mobile.

HYT is the Analog branch of Hytera a chinese analog/digital radio manufacturer. This radios has a good impact on commercial and ham users as being tough and versatile.

I get in touch with a fellow ham operator (CM7ETY) who is the Fleet Operator with many of this radios, and it gently agree to borrow me one of this, with he software, programming cable, etc...

It seems like this radios have at least 4 main versions in firmware, and every firmware main version has it's own programming software.

I will start with he most new firmware family 2.4.x ones and he see what is the difference in each one to see if I can make a unique driver for all versions.

The V at the end is for the VHF version.

73.

Actions #1

Updated by Pavel Milanes almost 9 years ago

  • Tracker changed from Bug to New Model
  • Equipment Loan/Gift Offered set to No

Wrongly summited as Bug, fixed as New Model.

Sorry.

Actions #2

Updated by Pavel Milanes almost 9 years ago

I have figured out the communications protocol for this radio and doing some mapping of the channel data (around 80%), but...

They are using a checksum algorithm that is known to me. The real implication of this is the lack of uploading capabilities until we known the checksum algorithm.

I have tested some algorithms inside other Chirp's driver and none fit in.

I can do the download part, but it's worthless if we can't upload the modified data back to the radio.

Note: One strange particularity of the algorithm: after summing a 256 block of 0xFF data the checksum keep going down just one bit, if you receive another 256 byte of empty data (0xFF) the checksum of that packet will be equal to the previous packet checksum minus one... a kind of accumulative checksum...

Any tip/help will be appreciated.

73 CO7WT.

Actions #3

Updated by Pavel Milanes almost 9 years ago

  • Status changed from New to Closed
  • Target version set to 0.5.0

I have dedicated a few hours to analyze and try to break the checksum in the comm protocol: failure.

I'm closing this issue as without the checksum it's worthless to implement a read only driver.

Actions

Also available in: Atom PDF