[chirp_devel] FT-450D Test Errors
OK, I am having a dilemma.. I have the new Yaesu FT-450D driver working 99.876% perfectly (+/- 10%). My problem is that it fails run_tests with two very specific issues- 1) The FT-450D uses a secondary 2-bit value to modify the base 'mode' for data modes. This causes the Brute Force test to fail the compare_mem test, since it doesn't know about that modifier. 2) The FT-450D supports a Memory Group on/off option that changes the memory display format from simple 0-500 channels, to 10 50-channel groups (Ex: MEM-02-01, for number 51). Since the radio does not store this info in any form of bank memory, I have chosen to use the Comment field to show the group index when that option is enabled. Therefore this causes run_tests Edges and Brute Force tests to fail compare_mem when it sets a blank channel name and I overwrite it.
Since the driver works now for all upload and download configurations and modes, should I care that it fails these tests?
- The FT-450D uses a secondary 2-bit value to modify the base 'mode'
for data modes. This causes the Brute Force test to fail the compare_mem test, since it doesn't know about that modifier.
Okay, but the test is comparing the Memory objects, which should be stable across a set/get operation. What is the actual test failure you're getting and why is it failing to set one value and return the same?
- The FT-450D supports a Memory Group on/off option that changes the
memory display format from simple 0-500 channels, to 10 50-channel groups (Ex: MEM-02-01, for number 51). Since the radio does not store this info in any form of bank memory, I have chosen to use the Comment field to show the group index when that option is enabled. Therefore this causes run_tests Edges and Brute Force tests to fail compare_mem when it sets a blank channel name and I overwrite it.
You shouldn't do that, because the comment is expected to be owned by the user, and editable through the UI, which is why it's failing. I would recommend just exposing the memories as 0-500, independent of what that setting is set to. Maybe we should come up with some other way to expose extra "tip" type information on a memory, but hacking comment isn't the right thing in the meantime.
Since the driver works now for all upload and download configurations and modes, should I care that it fails these tests?
Yes, you should care because I want it to pass tests before we merge it :)
Let's work out your mode issue, and drop the comment behavior for the time being so we can get the base patch merged and then we can talk about what to do about your group mapping thing, okay?
--Dan
I'm fine with removing the comment trick, but it would be great to eventually support a generated (not saved in the image file) extra UI field. I have fixed the the compare mode problem, so that test is passing, so all tests are passing once I removed the comment trick.
Rick DeWitt AA0RD Sequim, Washington, USA 360-681-3494
On 5/30/2018 9:43 AM, Dan Smith via chirp_devel wrote:
- The FT-450D uses a secondary 2-bit value to modify the base 'mode'
for data modes. This causes the Brute Force test to fail the compare_mem test, since it doesn't know about that modifier.
Okay, but the test is comparing the Memory objects, which should be stable across a set/get operation. What is the actual test failure you're getting and why is it failing to set one value and return the same?
- The FT-450D supports a Memory Group on/off option that changes the
memory display format from simple 0-500 channels, to 10 50-channel groups (Ex: MEM-02-01, for number 51). Since the radio does not store this info in any form of bank memory, I have chosen to use the Comment field to show the group index when that option is enabled. Therefore this causes run_tests Edges and Brute Force tests to fail compare_mem when it sets a blank channel name and I overwrite it.
You shouldn't do that, because the comment is expected to be owned by the user, and editable through the UI, which is why it's failing. I would recommend just exposing the memories as 0-500, independent of what that setting is set to. Maybe we should come up with some other way to expose extra "tip" type information on a memory, but hacking comment isn't the right thing in the meantime.
Since the driver works now for all upload and download configurations and modes, should I care that it fails these tests?
Yes, you should care because I want it to pass tests before we merge it :)
Let's work out your mode issue, and drop the comment behavior for the time being so we can get the base patch merged and then we can talk about what to do about your group mapping thing, okay?
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (2)
-
Dan Smith -
Rick DeWitt