View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002578||3 - Current Dev List||Bug||public||2018-03-07 08:52||2018-05-12 01:11|
|Target Version||Fixed in Version|
|Summary||0002578: Ten Tec Orion II 40 meter issue|
|Description||I spoke to Mike about this at Orlando Hamcation...|
There is a bug in the TT Orioin Rig Control code that causes Rig Control to stop working (ie not get updates from the radio) when it is tuned between a specific frequency range. It occurs when the radio is tuned between ~ 7.1467 and 7.147 MHz. The frequency field of Rig Control goes blank if the radio is tuned to that range of frequencies. If I tune away from the range, things start to work again.
To test manually, bypassing Rig Control: AF queries the current frequency. *AF sets the desired frequency. I was able to successfully set the frequency of the Orion to 7.1469 and 7.147 MHz. I was also able to properly query it. So there may be something flaky in the HRD code that causes the issue described in my post above. I cannot find any issues by sending the commands and queries directly to the radio.
|Steps To Reproduce||Turn on Ten Tec Orion/Orion II.|
Set frequency of radio to 7.1468 MHz.
Connect via Rig Control.
Rig Control fails to connect.
With Rig Control properly connected, return radio to 7.1468 MHz. Rig Control loses connection.
|Additional Information||Mike said that he suspected some frequency gap in the definition for the Orion II.|
Interestingly, if I set Rig Control to the Eagle and then connect to the Orion II, frequency reads fine in that range. So a clue may be in a comparison of the frequency range code for the two radios.
|Tags||No tags attached.|
There are no frequency definitions in Rig Control for individual radios.
I don't think there is a way to investigate this issue without access to the radio. TenTec is no longer in business; this radio is extremely hard to find used, and when it does appear it is dearly expensive.
OK, I think I've got a good theory about what's going on.
Diagnosing this without the radio is difficult. To add to the complexity is the fact that TenTec is out of business, so documentation and manuals aren't easy to find. On top of it, some documentation (and the HRD code) refers to model numbers, while other documentation (and most of our customers) refer to model names.
Without the radio, without solid documentation, I still think I have a diagnosis.
This issue is reported here against the Orion II model. I don't know if this bug affects other TenTec models or not.
As far as I can tell, the Orion II is the TenTec 566. The HRD code does not discern between the Orion (not II) and the Orion II. The Orion (not II) is model 565.
I do not have access to a programming manual for either the 566. I do have a manual for the 565, Orion (not II).
This report says that radio uses "AF" to read the frequency and "*AF" to write the frequency. This doesn't match the HRD code, which uses "?A" to read the frequency of VFO A, and "A" to set the frequency of VFO B. The HRD code does not match the programming manual, which agrees that "AF" and "*AF" should be used.
The 565 manual explains that the radio accepts both commands. They commands are not identical, however. The "A" and "?A" commands format the freuqency as ASCII letters, with a decimal, in megahertz. Tuning 7.1468 should be done by sending "*AF7.1468<cr>" to the radio.
But the radio could also be set to 7.1468 by sending "*A<6D><0D><30><cr>" to the radio.
7.1468 is in the range of problematic frequencies. Notably, the bytewise representation of the frequency involves the byte <OD>, which is the same as a carriage return. If we ask the radio its freuqency using "?A" and the radio is tuned to 7.1468 MHz, then the radio would respond with "@A<6D><0D><30><cr>".
This representation is problematic; it's the same as "@A<6D><cr><30><cr>".
In the Rig Control code, CConnection::TenTecReadFreqHertz() for any radio but the TenTec 599 (the Eagle, I believe) calls CConnection::TenTecReadHexInt() with the "?A" command and passes a parameter to the function to tell it to expect four characters.
TenTecReadHexInt() calls TenTecReadHexString() with the "?A" command and the four-count. TenTecReadHexString() has a loop which retries the commands, fiddling with some timing hacks. But it eventually calls TenTecSendString(), which sends the "?A" command string to the radio with a call to SendString().
At this point, the command has been sent, so TenTecReadHexString() calls ReadString() to read the response. ReadString() is informed of the expected four count as well as the expected terminator of the read operation, which is an 0x0D <cr> character. It turns around and calls CComPort::ReadString(), which also learns terminating <cr> character but is not told the expected length.
CComPort::ReadString() reads a byte at a time, accumulating the the bytes into an array. But it stops the first time it sees a termination character, which is <cr>.
So, it's here that things go wrong. When the radio sends "@A<6D><cr><30><cr>", the reading stops at the first <cr> character and only "@A<6D><cr>" is read. That leaves "<30><cr>" unread.
The ReadString() function doesn't return any indication of why it stopped reading. When it returns to ReadString(), that function tests the read string by looking at the last character. If the last character read is the expected terminating character, the read operation is assumed to be successful. The expected length (in our case, 4) is not considered.
ReadString() returns to TenTecReadHexString(), and things become a disaster. This function has lots of evidence of trian-and-error coding: commented out tests, messages boxes, trace messages. It's an absolute disaster of multiple code paths for different radios, and hacky little tricks to fiddle with response strings to hopefully get them to match.
Focusing on the code path for the Orion (not II) and Orion II radios, we find that the code checks to see that the response begins with "@". The repsonse is then tested to see that the command was echoed back; that we get "A" as the next character, in our specific example. Finally, the expected length is tested: if the character at the expected length (even i fthat length exceeds the length actually read -- Oops!) is 0x0D, regardless of the specified termination character, the response is ignored.
Otherwise, the response is built into a string and returned to the caller.
But because the 0x0D stopped the read early for the hex-byte representation of the frequencies that are a problem for this radio, then we have a bogus frequency response. The hacky code tries five times, fiddling with timing each time. That masks the error and slows down the UI response to the radio; it's foolish code.
This problem is local to the 40 meter band because the hex representations of the frequencies in that band are the only ones that involve an 0x0D character in them; see the attached spreadsheet.
TenTec Hex Frequency Ranges.xlsx (12,283 bytes)
Without acccess to the radio, testing my theory is difficult. Here are possible paths forward:
1) Do nothing. That's great, because it doesn't risk breaking other radios.
2) For the Orion (not II) and Orion II only, we send the commands that use ASCII-formatted frequencies. These seem to work correctly. The fix is simple, and the change is local to the Orion (not II) and Orion II radios.
3) Make the same fix as #2, but also for other specific radios. Maybe there are some, maybe there are none.
4) Fix the issue of the expected length for all radios and all callers to the involved ReadString() functions. This probably reveals other bugs with the way the radio is handled by Rig Control, but would require exhaustive testing of features for the radios involved. Since the radios aren't available, that's unlikely.
#2 certainly sounds reasonable and I am available to test.
Or, wait until the switch to OmniRig/Hamlib type radio support and we can switch to that. Depends upon what the timeline will be.
||I don't know what "the switch to OmniRig/Hamlib type radio support" is.|
Version 1.2 of the programmers manual covers both the 566 and 565. They are identical from a programming code perspective. if you don't have version 1.2 let me know and I'll upload it.
Great research on the root cause of the issue. I do have an Eagle and have not run into this issue but I can test for it if useful to the effort.
Ask Mike C. about the reference to OmniRig/Hamlib type radio support, this is something he mentioned in Orlando.
||Thanks for offering! That's the the version of the manual that I have, but it makes no mention of the 566.|
||fixed (I think) with this checkin: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4051|
||@K7ZCZ, Mike let me know if you have something for me to test or I can catch it in the next Beta build. Thanks!|
||I feel pretty good about the fix; if you can commit to testing this in the next beta-available build, it would be best.|
Not yet fixed as of build 837.
But, the situation is improved. If I use rig control to tune the radio to a frequency in the problematic range, the radio does not change frequency and in a second or so rig control changes back to the original frequency, presumably on next read from the radio.
In the other direction, if I tune the radio to a frequency within the problematic range, rig control reflects the updated frequency.
So were seem to be halfway there.
Not yet fixed in build 839.
Starting with radio at 7.1467 MHz LSB, I attempted to use the up arrow on the 100 hz place to tune up to 7.1468 MHz. Rig control displays 7.1468 for one second after keypress, then reverts to 7.1467 MHz. Radio remains at 7.1467 Mhz.
Using VFO A physical knob on the radio, I can tune to 7.1468 Mhz and rig control properly reflects the update.
Now starting from 7.1468 MHz, if I press the up arrow, Rig Control reflects 7.1469 MHz for a second and then reverts to 7.1468 MHz. Radio remains at 7.1468 MHz.
If I use Rig Control to tune up to 7.147 MHz that works as expected.
||That's disappointing, though I guess a little progress is better than none. I can try to take another stab, but statically working on the code without access to the radio is very inefficient, so it's hard to give this issue much priority. This is a rare radio, and is out of production, so it doesn't feel like the effort to support it is warranted.|
||Sent it back to Assigned based on K2DLS feedback.|
|2018-03-07 08:52||k2dls||New Issue|
|2018-04-06 18:24||K7ZCZ||Note Added: 0004733|
|2018-04-06 20:33||K7ZCZ||Note Added: 0004734|
|2018-04-06 20:34||K7ZCZ||File Added: TenTec Hex Frequency Ranges.xlsx|
|2018-04-06 20:43||K7ZCZ||Note Added: 0004735|
|2018-04-06 22:06||k2dls||Note Added: 0004736|
|2018-04-07 08:35||K7ZCZ||Note Added: 0004743|
|2018-04-07 15:55||k2dls||Note Added: 0004752|
|2018-04-12 14:54||K7ZCZ||Assigned To||=> K7ZCZ|
|2018-04-12 14:54||K7ZCZ||Status||new => assigned|
|2018-04-12 17:05||K7ZCZ||Note Added: 0004811|
|2018-04-12 17:06||K7ZCZ||Status||assigned => resolved|
|2018-04-12 17:06||K7ZCZ||Resolution||open => fixed|
|2018-04-12 17:06||K7ZCZ||Testing||=> Not Started|
|2018-04-12 17:06||K7ZCZ||Note Added: 0004812|
|2018-04-12 17:06||K7ZCZ||Project||1 - Backlog => 3 - Current Dev List|
|2018-04-14 19:26||k2dls||Note Added: 0004826|
|2018-04-17 07:01||K7ZCZ||Note Added: 0004851|
|2018-05-03 20:10||K7ZCZ||Fixed in Version||=> 184.108.40.2067|
|2018-05-04 13:03||k2dls||Note Added: 0004948|
|2018-05-10 08:32||k2dls||Note Added: 0004985|
|2018-05-10 09:56||K7ZCZ||Note Added: 0004986|
|2018-05-12 01:11||WA9PIE||Status||resolved => assigned|
|2018-05-12 01:11||WA9PIE||Resolution||fixed => reopened|
|2018-05-12 01:11||WA9PIE||Fixed in Version||220.127.116.117 =>|
|2018-05-12 01:11||WA9PIE||Note Added: 0005014|