Bug #11819
closed
TypeError: unsupported operand type(s) for /: 'arrayDataElement' and 'float'
Added by Johnny A. 14 days ago.
Updated 14 days ago.
Model affected:
IJV_V3 Quansheng UV-K5
I read the instructions above:
Yes
Description
TypeError: unsupported operand type(s) for /: 'arrayDataElement' and 'float'(Describe what you were doing)
Just typing Settings
(Describe what actually happened instead)
(Has this ever worked before? New radio? Does it work with OEM software?)
- Status changed from New to Rejected
Per the IssueInstructions you indicated you read, a debug log is required in order to diagnose your issue. However, I can tell from the model string that you're loading a module that is not part of chirp. I can almost guarantee you based on the TypeError that the bug is in that module, but I can't say for sure without a debug log. If you want to upload your debug log I can confirm that for you, but I won't be able to fix it because that driver is not part of chirp - it's written by someone else. You should take it up with them and also encourage them to submit it for inclusion in chirp so you (a) don't have to load it manually and (b) have it be supportable.
I'll mark this as rejected on the assumption above, but if I'm wrong, feel free to upload a debug log and I'll re-open it if appropriate.
Hello Dan, thank you for your quick reply.Unfortunately I can't reach the developer of the Chirp module. But I don't think the module is solely to blame for the error, because everything works perfectly up to Chirp version 20250124. I'll send you a separate debug file. Many thanks, Johnny from Vienna/Austria.Von meinem Samsung Galaxy gesendet.-------- Ursprüngliche Nachricht --------Von: Dan Smith redmine@chirpmyradio.com Datum: 09.02.25 17:03 (GMT+01:00) An: j.p.s@gmx.at Betreff: CHIRP - Bug #11819 TypeError: unsupported operand
type(s) for /: 'arrayDataElement' and 'float'
Yes, the module is to blame (as shown by the debug log in the other issue #11821 that was opened for this). CHIRP internals change all the time. All the drivers in the tree are tested together, and when something changes, all the drivers get changed to match. Your external module is not part of CHIRP, which means it will forever be breaking because when CHIRP changes, it does not. CHIRP does not provide a stable API for external modules and thus out-of-tree drivers like this will always be constantly breaking. The function you're using to load the module is for developers to work on drivers, not for users to load drivers that are not included in the tree. That's why CHIRP warns you when you enable developer mode, and warns you again when you load the module.
I'd recommend you go to a firmware that has a driver supported in tree, or figure out how to get the author of that driver to submit it for inclusion in CHIRP. You should also really think about whether or not you want to be loading that driver from an author that doesn't even maintain it and thus give it access to all the files on your computer. If it were me, I would surely not trust it.
Also available in: Atom
PDF