[chirp_devel] run_tests Error
I am changing the leixen.py to better detect the saved data file. It works perfectly detecting a Leixen VV-898 data file or a Jetstream JT270M data file but I am getting a failure when executing the "run_tests" utility.
Leixen VV-898 Detect ←[1;41m FAILED:←[0m Failed to detect
The Jetstream JT270M Detect test passes.
Any ideas what it could be?
Jim KC9HI
On Tue, Dec 23, 2014 at 5:08 PM, Jim Unroe rock.unroe@gmail.com wrote:
I am changing the leixen.py to better detect the saved data file. It works perfectly detecting a Leixen VV-898 data file or a Jetstream JT270M data file but I am getting a failure when executing the "run_tests" utility.
Leixen VV-898 Detect ←[1;41m FAILED:←[0m Failed to detect
The Jetstream JT270M Detect test passes.
Any ideas what it could be?
Maybe the VV-898 images is being detected as a JT270M. Is there a difference? Are the two differentiated when opening normally with Chirp?
Tom KD7LXL
On Tue, Dec 23, 2014 at 8:24 PM, Tom Hayward tom@tomh.us wrote:
On Tue, Dec 23, 2014 at 5:08 PM, Jim Unroe rock.unroe@gmail.com wrote:
I am changing the leixen.py to better detect the saved data file. It works perfectly detecting a Leixen VV-898 data file or a Jetstream JT270M data file but I am getting a failure when executing the "run_tests" utility.
Leixen VV-898 Detect ←[1;41m FAILED:←[0m Failed to detect
The Jetstream JT270M Detect test passes.
Any ideas what it could be?
Maybe the VV-898 images is being detected as a JT270M. Is there a difference? Are the two differentiated when opening normally with Chirp?
Tom KD7LXL
Yes. I found a couple of differences besides the Custom Message that is currently being used. CHIRP detects the files just fine. I can switch back to the original code and the test runs without any issues.
Jim KC9HI
On Tue, Dec 23, 2014 at 8:37 PM, Jim Unroe rock.unroe@gmail.com wrote:
On Tue, Dec 23, 2014 at 8:24 PM, Tom Hayward tom@tomh.us wrote:
On Tue, Dec 23, 2014 at 5:08 PM, Jim Unroe rock.unroe@gmail.com wrote:
I am changing the leixen.py to better detect the saved data file. It works perfectly detecting a Leixen VV-898 data file or a Jetstream JT270M data file but I am getting a failure when executing the "run_tests" utility.
Leixen VV-898 Detect ←[1;41m FAILED:←[0m Failed to detect
The Jetstream JT270M Detect test passes.
Any ideas what it could be?
Maybe the VV-898 images is being detected as a JT270M. Is there a difference? Are the two differentiated when opening normally with Chirp?
Tom KD7LXL
Yes. I found a couple of differences besides the Custom Message that is currently being used. CHIRP detects the files just fine. I can switch back to the original code and the test runs without any issues.
Jim KC9HI
Tom,
I think I figured it out. The tests run against the .img files in the repository. The one for the Leixen isn't a good .img since it only read the memories and names.
What is the correct way to submit a image file for this. Just upload it to my issue?
Jim KC9HI
I think I figured it out. The tests run against the .img files in the repository. The one for the Leixen isn't a good .img since it only read the memories and names.
It came from a real radio though, right? If so, we probably need to make sure it's still handled properly.
You can look in tests/logs/ for more details on each run and the associated failure.
What is the correct way to submit a image file for this. Just upload it to my issue?
If you do need to get a different image into the tree, you can email it directly to me or upload it to your issue. The latter is actually a little easier for me.
--Dan
On Wed, Dec 24, 2014 at 4:05 PM, Dan Smith dsmith@danplanet.com wrote:
I think I figured it out. The tests run against the .img files in the repository. The one for the Leixen isn't a good .img since it only read the memories and names.
It came from a real radio though, right? If so, we probably need to make sure it's still handled properly.
Yes. Straight out of my radio.
You can look in tests/logs/ for more details on each run and the associated failure.
The "Leixen_VV-898.img" in the repository has no data from 0x0000 to 0x0d00 (except for 0x0900 to 0x0906 which is the Custom Display message). The current driver intentionally skips over this area. This area is where all of the settings are. From 0x0D00 to 0x2000 are only channels and names.
The failure is because I am changing the match_model to look at a different area to detect the data file. The current place is editable by the OEM software and once the user changes it, CHIRP no longer detects the image and it had to be manually selected. The current driver fills almost all of the data from 0x0000 to 0x0D00 with 0xFF as it is skipped. The data that should be there for my patch to detect isn't there and it won't be until my first patch is approved.
What is the correct way to submit a image file for this. Just upload it to my issue?
If you do need to get a different image into the tree, you can email it directly to me or upload it to your issue. The latter is actually a little easier for me.
I have already uploaded it to my issue.
--Dan
Thanks, Jim
The "Leixen_VV-898.img" in the repository has no data from 0x0000 to 0x0d00 (except for 0x0900 to 0x0906 which is the Custom Display message). The current driver intentionally skips over this area. This area is where all of the settings are. From 0x0D00 to 0x2000 are only channels and names.
The failure is because I am changing the match_model to look at a different area to detect the data file. The current place is editable by the OEM software and once the user changes it, CHIRP no longer detects the image and it had to be manually selected. The current driver fills almost all of the data from 0x0000 to 0x0D00 with 0xFF as it is skipped. The data that should be there for my patch to detect isn't there and it won't be until my first patch is approved.
Okay, I just don't want to abandon users that currently have images that work, which won't after this change. However, if the current method for detection is prone to failure after changing a string, then those were likely to break at some point anyway.
Thanks!
--Dan
Okay, I just don't want to abandon users that currently have images that work, which won't after this change. However, if the current method for detection is prone to failure after changing a string, then those were likely to break at some point anyway.
Thanks!
--Dan
Dan,
Good point. How about if I will submit a patch that will accept a match either way?
Jim
On Wed, Dec 24, 2014 at 7:59 PM, Dan Smith dsmith@danplanet.com wrote:
Good point. How about if I will submit a patch that will accept a match either way?
Yep, if it's reliable for the old images at least, it's a nice thing to avoid breaking users' images :)
Thanks!
--Dan
Already done and submitted.
Jim
On Dec 24, 2014 2:57 PM, "Jim Unroe" rock.unroe@gmail.com wrote:
Okay, I just don't want to abandon users that currently have images that work, which won't after this change. However, if the current method for detection is prone to failure after changing a string, then those were likely to break at some point anyway.
Thanks!
--Dan
Dan,
Good point. How about if I will submit a patch that will accept a match either way?
You'll have to make sure you don't upload one of these full images to the radio. You'll write 0xFF across the whole settings block. I'd just warn the user that they need to re-download--their img is deprecated format.
Tom KD7LXL
On Wed, Dec 24, 2014 at 9:33 PM, Tom Hayward tom@tomh.us wrote:
On Dec 24, 2014 2:57 PM, "Jim Unroe" rock.unroe@gmail.com wrote:
Okay, I just don't want to abandon users that currently have images that work, which won't after this change. However, if the current method for detection is prone to failure after changing a string, then those were likely to break at some point anyway.
Thanks!
--Dan
Dan,
Good point. How about if I will submit a patch that will accept a match either way?
You'll have to make sure you don't upload one of these full images to the radio. You'll write 0xFF across the whole settings block. I'd just warn the user that they need to re-download--their img is deprecated format.
Tom KD7LXL
Ouch. You are right. Maybe this should be pulled? Maybe skip settings block if old image is detected?
Jim KC9HI
On Dec 24, 2014 7:02 PM, "Jim Unroe" rock.unroe@gmail.com wrote:
Ouch. You are right. Maybe this should be pulled? Maybe skip settings block if old image is detected?
You could modify the upload function such that it will not upload that range if it's full of 0xff.
Tom KD7LXL
You'll have to make sure you don't upload one of these full images to the radio. You'll write 0xFF across the whole settings block. I'd just warn the user that they need to re-download--their img is deprecated format.
Tom KD7LXL
Ouch. You are right. Maybe this should be pulled? Maybe skip settings block if old image is detected?
Jim KC9HI
Dan,
I wasn't clear. I meant to pull the whole series of 3. It is the first one that causes the writing the 0xFF issue. Anyway I just submitted a patch that will take care of it. Memories and Names only, unless the image is detected as being the new version.
Thanks Dan and Tom for you help with this. Merry Christmas.
Jim KC9HI
I wasn't clear. I meant to pull the whole series of 3. It is the first one that causes the writing the 0xFF issue. Anyway I just submitted a patch that will take care of it. Memories and Names only, unless the image is detected as being the new version.
No problem, I just saw the mail right before bed and didn't put much thought into it.
Got this one applied, thanks!
--Dan
On Thu, Dec 25, 2014 at 11:29 AM, Dan Smith dsmith@danplanet.com wrote:
I wasn't clear. I meant to pull the whole series of 3. It is the first one that causes the writing the 0xFF issue. Anyway I just submitted a patch that will take care of it. Memories and Names only, unless the image is detected as being the new version.
No problem, I just saw the mail right before bed and didn't put much thought into it.
Got this one applied, thanks!
--Dan
Is there any chance of pushing it out today to minimize problems from those trying to upload old "images"?
Jim
Is there any chance of pushing it out today to minimize problems from those trying to upload old "images"?
I pushed the patch already. I suppose I can try generating new build with a -extra tag or something. Not sure how the ppa build process will like that, but we'll see.
I wouldn't sweat over it too much, given that it's just one day, and a day few people should be futzing with their radios :)
--Dan
On Thu, Dec 25, 2014 at 12:25 PM, Dan Smith dsmith@danplanet.com wrote:
Is there any chance of pushing it out today to minimize problems from those trying to upload old "images"?
I pushed the patch already. I suppose I can try generating new build with a -extra tag or something. Not sure how the ppa build process will like that, but we'll see.
I wouldn't sweat over it too much, given that it's just one day, and a day few people should be futzing with their radios :)
--Dan
Dan,
I can wait. Thanks.
Jim
participants (3)
-
Dan Smith -
Jim Unroe -
Tom Hayward