Closed F9Alejandro closed 1 year ago
This needs further investigation. There could be a bug in the way GUI apps grab information from the CU and is causing issues with how data is displayed. (Nick slots could start from 0 instead of the intended 1 based on how the cli works)
The chameleon slot offset is from 0 start(in firmware). However, when using a chameleon in practice, it is necessary to map the card slot to the card slot number printed on the hardware.
So, this is py CLI bug.
Thank you for the heads up. I know a quick and dirty way to fix it but I believe it would be better to put it as a const enum instead that remaps int 1 to int 0 for nick specific.
Slot index decrement
But slot function lost it.
That makes more sense! Thank you for the clarification.
Yes, enum type is a strong solution.
Best to use enums for the slot in general if that is the case. It makes it easier to change if the firmware were to make a change to how information is being stored.
If I have time, I will refactor it using enumeration types, or if you know how to write PY script, you can push a PR, and the community will be very grateful to you.
I will have to learn how python does their enums. Mainly been using TS, C++, Rust, and Golang. It is possible to make the change. I could also work with szymex73 on getting this working as well. They are currently working on an overhaul to the way how the cli functions with autocomplete and fixes the issue with using any other keys except for left and right arrows making the line messed up.
Please see #52 as this should be able to fix the issue that is happening. I didn't do extensive testing mainly just the 'hw slot nick get' command with '-h' and '-s -st' just to make sure it doesn't crash or do something it shouldn't. Since it will only accept a number 1 - 8 there should be no issue with the conversion from name to value (function should really be called ntov instead of fix now that I think about it)
Perfect, i need some time to test all cmd for slot index required. LoL
Closing this as the PR has been merged and I got some valuable insight from @doegox. Thank you again!
Issue:
using command
hw slot nick get -s 1 -st 1
starts at 1 instead of expected 0.Expected:
Returns slot 1 nickname
Actual:
Returns slot 2 nickname (if it exists)
This happens with all slots. When checking the gui apps it shows slot 2 and above have been named instead of the intended slot 1. Changing the sent slot value from
slot_num
toint(slot_num-1)
works as expected. Not an ideal solution though. if this could be done firmware side instead this would make it easier and will prevent the need to modify the cli code and add hardcoded values.Before change:
After change: