With the old logic, 1.5 MHz becomes 1.5 m before suffix evaluation.
That can result in m being interpreted as milli instead of MHz being interpreted as mega, which sends a completely wrong numeric value to the instrument.
Example
1.5 MHz should become:
1500000
With the old parser it could be interpreted as milli-scale instead.
Fix approach
Replace the strip-and-guess logic with a regex-based parser that reads numeric value and suffix in one pass, using longest suffix match first.
This avoids mhz collapsing into m and makes unit handling much more robust.
Status
Local fix already implemented in the current v0.2 working copy.
Still needs commit, push, and hardware verification before closing.
### Problem
`human_to_eng()` can interpret values such as `1.5 MHz` incorrectly because the old strip order removes `hz` before suffix matching.
### Current code
```python
t = s.strip().lower().replace("vpp", "").replace("v", "")
t = t.replace("hz", "").replace("deg", "")
```
### Why this is a bug
With the old logic, `1.5 MHz` becomes `1.5 m` before suffix evaluation.
That can result in `m` being interpreted as milli instead of `MHz` being interpreted as mega, which sends a completely wrong numeric value to the instrument.
### Example
`1.5 MHz` should become:
```text
1500000
```
With the old parser it could be interpreted as milli-scale instead.
### Fix approach
Replace the strip-and-guess logic with a regex-based parser that reads numeric value and suffix in one pass, using longest suffix match first.
This avoids `mhz` collapsing into `m` and makes unit handling much more robust.
### Status
Local fix already implemented in the current v0.2 working copy.
Still needs commit, push, and hardware verification before closing.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
human_to_eng()can interpret values such as1.5 MHzincorrectly because the old strip order removeshzbefore suffix matching.Current code
Why this is a bug
With the old logic,
1.5 MHzbecomes1.5 mbefore suffix evaluation.That can result in
mbeing interpreted as milli instead ofMHzbeing interpreted as mega, which sends a completely wrong numeric value to the instrument.Example
1.5 MHzshould become:With the old parser it could be interpreted as milli-scale instead.
Fix approach
Replace the strip-and-guess logic with a regex-based parser that reads numeric value and suffix in one pass, using longest suffix match first.
This avoids
mhzcollapsing intomand makes unit handling much more robust.Status
Local fix already implemented in the current v0.2 working copy.
Still needs commit, push, and hardware verification before closing.
human_to_eng() parses MHz incorrectlyto [Bug]: human_to_eng() parses MHz incorrectly