WE  NEED  YOUR  HELP !!

WHY?

As mentioned in the FAQ, "we set out with the intention of also supporting the Z-350 module as used in the 70-155/255 80-channel Syntrx portables. However at this time only limited support for the Z-350 is possible .  Using the appropriate 70-1071 adaptor, the 70-1000X can read/program these modules as well as read/save a disk file.  While the contents of the module can be displayed, editing is not possible as there is some per-channel data content which we are unable to generate.  The key to this information is probably "out there" somewhere, and we have spent a lot of time searching for it, but until we have that information there can be no further progress."

And also "If you know of anyone who might have information on the data storage within the Z-350 module we would like you to contact us so we can progress towards full Z-350 support, which remains our goal."

We want to complete this area so that the users of Syntech portables can enjoy the benefits of affordable and convenient reprogramming.  But we are currently stymied.  Why?  Here is a summary of the current situation:

• We have available a few Z-350 modules, all with identical content.
• The expected data content for channel frequency, tone, scan and tuned circuit tracking are all straightforward and resolved.
• There is some additional content for which there is no apparent purpose (and for which there is no parallel in the ST1's Z-273 module).  This per-channel data varies in "visible sympathy" with the frequency data.  It may be a checksum or contain parity info, or both.  Let's call it a checksum.
• Try as we might, no unique or logical "algorithm" has been ascertained to explain this checksum.
• Until we can identify the algorithm used to generate this checksum, we are unable to construct the data block for a new/edited channel.

How might YOU be able to assist ?

There are two thrusts to our efforts on the Z-350.

First, to try and identify the scope of the checksum.  In the band 450-470 MHz there are 1600 odd channels at 12.5 kHz spacing.  The data we have is for a block of 64 consecutive 25kHz-spaced channels in that band.  This was VERY convenient for reverse-engineering the frequency storage (which we have completed), but is clearly only a small sample of the potential data.  There are seven bits of associated data of which four bits (in our sample data) change value.  The remaining three bits are always 0 (again, in our sample data).  But our data is constrained to 25 kHz steps - only the EVEN 12.5 kHz step multiples.  We have no insight into whether the other three bits might change on (a) odd multiples, or (b) outside the 1.6 MHz range of our data samples.  If we could get to see more Z-350 data we might be able to learn more.

Second, to try and ascertain an algorithm which can "generate" the checksum for at least the channel data we have to hand.  Now there are 17 bits assigned for frequency data in each channel's entry.  The remaining seven are the mystery.  If only four of those bits are ever involved in the checksum, my maths tells me that there are 2^17/2^4 or 2^13 unique algorithms that will generate the checksum for that channel.  But with 64 Rx and 64 Tx  frequency entries, the number of algorithms which will work on all those entries is (2^13/2^7) or 2^6.  Wow!  Only 64 algorithms!!  64 needles in that haystack!  So all we need to do is (a) identify those 2^13 algorithms, (b) test each one on each data set, and (b) retain only those that work for our 64 channels of data.  Now that wouldn't be too impossible, assuming we knew in advance which of those 17 bits were or weren't used in the alghorithm.  If this all sounds too hard, that is because it is!

Normally by "looking" at the data the patterns become apparent, but not here.  For example, a pattern emerged  - that was both simple and plausible, both expected attributes - which provided the answers for the first 6 channels.  But then it "broke", not matching subsequent channel data.  What ALSO changed at that point was the tracking data, so is that also part of the algorithm input? We don't know.  Bigger haystack?

Subsequently we changed the CTCSS data on one channel and the radio reported Error 94 on that channel.  Uh-oh, the haystack just got bigger.  It is no longer a 17-bit field.

If you have a particular "bent" for maths problems, please contact us and we can provide you with the raw Z-350 binary image to play with, as well as our "map" of what the information represents.   A fresh mind or two can often see what the original investigator doesn't.

Similarly if you can provide Z-350 data for our examination we would be pleased to receive it.  This may not be that simple of course, as the Midland 70-1000 can't save a binary file.  But nevertheless if you have Z-350 modules not committed to an active Syntech mobile, we'd also like to hear from you.  Our special thanks go to Dennis Bridgeman (Bridgeman Communications) for lending two Z-350 modules to aid our work.  This has provided much-needed information on VHF frequencies.

Our objective remains to solve this mystery and provide the software update to all our customers.

Thanks for your time spent reading this page.  We will certainly acknowledge all assistance received.