MobiFlight Community Support

Here i have record it:

http://www.nighteagle.de/Bug_Mobi802.mp4

0x01 is not the same as 0x1 if i have only one byte.

Hi nighteagle,

you can check it while reading your offset 0x3123. Then you can see the result of changing.
Best is to read the offset twice in new configs, on with filter 0x1 and one with filter 0xff
You should see that the result of 0x01 and 0x1 is the same.

Hello,

it works different and it is not the same i have test it out many times. I put an input like a button and use it with the offset then it is a different of working button or not. So it it more a problem behind the GUI. If i write it manaully and saved/okayed it then it works with the button - if i make it with the gui and the bit checkbox then the button is not working - more it is affected the other button on the other bits.

This is only if you use 1 byte - if you use 2 bytes the problem does not occur - so it seems a hexadecimal is minium 0x00 to 0xFF and there is not 0x0 - to 0xF.
So in the logic in background a 1 byte on a two byte HEX is a problem - like a programer-mistake. HEX is always minimum two bytes in programmer-languages.

If you want to depict 1 byte 1. bit then you have in every case a 0x01 no matter if you use one or two bytes. But the mobiflight make this to 0x1 and in the logic it means 0x10 and this is not the same.

You can test it out - if you use 0x1 on 1 byte you have not inputmask of the first bit! You have a inputmask of bit 4 because it is 10. So i see on my hardware that the button 5 is pressed instead the button 1. If i write manually 0x01 with 1 byte then button 1 works because inputmask of bit 0.

Hi nighteagle,

it doesn't look the way you portray it with me.
Basically, with numbers based on base 10, i.e. our known decimal system, basically all numbers have leading zeros. But nowhere is 00000345 written, only 345.
In digital technology, it has basically been agreed that these leading zeros should also be left out, only where they are supposed to represent a certain uniqueness, they are recorded. So here too 0x1 is the same as 0x01 (0000 0001). If it were, as you think, 0x10, the bits would look like this: 0001 0000.
0x always introduces a hexadecimal value. In this respect, the least that can be represented 0x0 is also written 0x00. Each place stands for 4 bits. One byte has 8 bits. But if the upper 4 bits are 0, I can write to 0xF because the decimal value is then 15. If you look at it (0xF0), it would be 240, which is both illogical and wrong. 0xF are nothing more than 0x ... 0000000F.
It may be that you use your spelling in this way and that it is okay for you, but other spellings are possible that are still logical and one-to-one. 0xF is not wrong because a leading 0 is missing.

I agree with you completely, the representation in MobiFlight confuses those who are used to a different reading, but it is not wrong.
Feel free to open the calculator in Windows and try it out there. F is always 15 there and it does not even accept 0F, which underlines my thesis about the omitted leading zero. On the other hand, if you enter F0, you will also see 240 correctly.

When you claim that HEX in programming languages ​​are always at least two bytes long, I would like to contradict you. 2 bytes would be 16 bits and that would also be 0x0000 to 0xFFFF for MF. However, you only complain that the representation of half a byte is wrong, i.e. as long as the values ​​are below 16. With a set byte length of 1 byte, MF provides exactly 8 bits for the filter and uses it correctly.

There is no difference here in relation to MobiFlight. I have defined a button as an input that writes the value 1 to the offset 0x66C0 for OnPress.
Then I wrote an output that reads the offset 0x66C0. I used 0x01 as a filter, which is displayed exactly as with you when you call up 0x1. If I now press the button, the FSUIPC value is 1 and the output value is also 1. It does not matter which value I write into the offset using the button. Whenever bit 0 is set (i.e. for odd numbers), this is also indicated to me in the offset by a 1, while the 0 is indicated for all even numbers. The behavior you described only shows itself with the values ​​00 .... 0F. Only at 0x10 (i.e. from 16) is displayed in two digits after 0x.

In this respect I do not see any incorrect behavior in the treatment by MobiFlight. We are happy to meet on Discord and I'll show you how I tested while screen sharing.

Hello,

it looks like you are misunderstanding me - do you a programmer? If not i understand why you not understand the problem.
A hex-value is minimum two bytes - one byte is not possible.
And this is the problem - in the GUI you can set one byte and mask with a hex of one byte - this is wrong!
First no problem you think - but second the problem is if you set 0x1 is not 0x01 because of definition of hex is two bytes.

Please test it out - you will see you can set it to bit 1 with 0x01 and then click okay - button press is bit 1 so fine here - open again and you see mobiflight short it to 0x1 click okay then button press is bit 5 - logically because it is 0x10 and not 0x01. Same with 0x2 and 0x20 - 0x4 and 0x40 all the same i have test it out with the buttons yesterday 3 hours. If you only make one setting and says okay then all is okay - but reopen and okay make the bug!!!!

If Mobiflight GUI short 0x01 to 0x1 - This is to prevent here to cancel the bug!!! No shorten 0x01 to 0x1 - so tell it sebastian he understand it in seconds i think.

You can not see it on the GUI on the checked bitmask - because of some GUI-Things sebastian makes here - but you see GUI short from 0x01 to 0x1 - thats wrong in the first state and on the second state you see it on connected hardware - the button on bit 1 don't work after you open it and it change by mobiflight to 0x1 and then you click okay and it is 0x10 instead of 0x01. Work around is write manually or use two bytes!

If you not see the BUG then i can not help you...

Hi nighteagle,

I also see what you see. Even if I enter it exactly as you specified, there is no bug here with me.

When I press my button, I set the offset to 255 (i.e. 0xFF). When looking at the offset in the output, I set the filter in the filter box to the first bit, i.e. 0x01. This value is then also in the filter. Now I press ok and close the wizard.
When I call the wizard again, the filter reads 0x1, but the output still has the value 1dec.
If I confirm the content of filter 0x1 with OK and exit the wizard again, the output still remains on 1dec and does not change to 16dec.

I can understand the behavior of MobiFlight described by you here, but the results you described do not appear. For me the result is always 1dec, so the filter works correctly. I was unable to generate a 16dec (0x10) in the output with these filter settings, sorry.

I sent you a few screenshots on Discord that should show you what I have set and how and what the results are.
In this respect, I see what you are describing, but there is no error in the calculations / filtering. In your video, you also don't show the output, i.e. the effects of changing from 0x01 to 0x1 (0).

I also ask myself why you assign a filter 0x01 to an input when you explicitly set it with the value 1?

Let's discuss this on Discord, it saves time and is much more effective.

Hi

Da du (nighteagle) ja Deutsch sprichst switche ich ausnahmsweise mal die Sprache hier.

Grundsätzlich zur ganzen Thematik will ich gar nicht groß einsteigen. Wie das nun aus Programmierer-Sicht richtig oder falsch ist, das ist ein eigenes Thema.
Das ist aber auch nicht relevant.... Denn für mich/uns ist am Ende nur wichtig... Ist ein funktionaler Bug in Mobiflight oder nicht ? Ob die "Anzeige" in der GUI nun 01 oder 1 anzeigt ist völlig egal solange sie in beiden Fällen das selbe tut und vor allem das richtige tut !

Deshalb hab ich das ganze getestet ( so wie ich es verstanden habe von dir).... Und ich muss leider sagen.... Ich konnte das Problem NICHT reproduzieren.

Testaufbau:

Ein Frischer Mega.... 2 Taster als Devices.
TestOffset 66C0 1 Byte INT.

Configs:
OUTPUT:
Eine Config die Ohne Device nur 66C0 liest ( 1 Byte alle Bits selected) . Rein zum Auslesen was der Offset am Ende macht.

INPUT:
Taster1 schreibt bei PRESS den Offset 66C0 auf Wert "0" . ( Alle Bits ausgewählt ) Dieser Taster ist nur zum "zurücksetzten" des Offsets um komfortabler zu testen.
Taster2 wird verwendet um diverse Tests durchzuführen.... Also um dein Problem zu reproduzieren.

Ablauf: SIM und MF auf RUN .... Taster 1 zum Reset.... Taster 2 für Test.... Dann wieder Taster 1 ..... Dann Taster 2 mit neuen Setting usw.....
**********
Resultat:
Egal ob ich Bit0 per click auswähle oder ob ich 0x1 oder 0x01 eingebe..... Egal ob die erste Auswahl genommen wird oder ob durch erneutes Öffnen MF automatisch von 01 auf 1 stellt....
In ALLEN Testsituation die ich probiert habe hat der Input stets den Offset auf "1" geschrieben.... Sprich nur den BIT-0 von False auf True gesetzt.
Also genau das was zu erwarten war und was er auch tun soll !


Der von dir gesagte Fall.... Also das MF hier 0x1 als 0x10 versteht und somit Bit4 (0001 0000) als Ziel genommen wird konnte ich NICHT nachstellen.
NUR wenn ich aktiv als Adresse 0x10 selber eingetippt habe wurde natürlich richtigerweise die Bitmask auf Bit4 gestellt.

*********************

ALSO:
Entweder ich habe dich falsch verstanden.... ODER.... Dein gemeldetes Problem hat eine andere Ursache.... Denn MF arbeitet nach meiner Ansicht 100% korrekt !

Wäre cool wenn du das aufklären könntest.... Also ob du das Problem "anders" nachstellen kannst. Wenns ein Bug ist dann müssen wir uns darum kümmern !

Moin,

hast du Bit 0 ausgewält - was steht da? 0x01 >> wäre schon verkehrt aber eigentlich richtig weil HEX ja immer zwei Byte hat - dann okay gedrückt und dann wieder geöffnet? Dann steht da 0x1 statt 0x01 - wäre wieder verkehrt oder eigentlich Richtig - wenn du dann wieder okay drückst ohne was zu ändern geht der Taster nur mit Bitmask auf Bit 0x10 statt 0x01. Wenn du das nicht nachstellen kannst machst du was anders. Bei mir gehts nicht - muss immer wieder bit 0 anklicken oder manuell 0x01 reinschreiben damit ich bit 1 am Taster der Hardware auch habe. Also wie gesagt Sebastian schaut es sich an - ich bin mit dem Thema durch.

Grüsse,

Hi again !

Nochmal damit wir uns nicht falsch verstehen......

Ob die GUI Anzeige nun 1... 01.... 0x1 oder 0x01 anzeigt.... Ob MF diesen Wert nach Close/Open selbständig ändert.....
Und ob das nun "richtig" oder "falsch" ist..... DAS interessiert mich nicht.
Diesen "optischen" Fehler kannst du gerne mit Sebastian intern besprechen !

Mein Test hat alle möglichen Variationen beinhaltet.
Ich hab Fenster mehrmals Geöffnet und geschlossen.... Ich hab die Bitmask per Click auf Bit "0" und auch durch Eingabe mit der Tastatur gesetzt.
ICh habe mit Size 1 BYte, 2 BYte und 4 BYte getestet.
Ich hab als eingabe alle 4 Variationen benutzt.... "0x01" "0x1" "01" und "1" .
Ich hab jeweils weitesgehend getestet was direkt danach passiert und was passiert wenn ich die Config bzw das Auswahlfeld nochmal öffne.
Ich hab MF mehrmals gespeichert, geschlossen und neu geladen

In ausnahmslos allen Fällen ( Die mir eingefallen sind) hat die Config IMMER Bit "0" geschrieben......
Also den 1 Byte Offset von Value 0 zu 1 geschrieben und NIEMALS auf Value 16 !

*******************

Ich behaupte nicht das du quatsch erzählst..... Im Gegenteil !
Ich hatte vor Jahren auch mal einen Fall bei dem etwas nicht richtig arbeitete...... 4 User hatten die gleiche MF Version und den gleichen MCC File. Bie 3 Ging es bei mir aber nicht !

Deshalb:

Wennd das wirklich ein Bug ist, dann muss er tiefer sein bzw System bezogen.
Wenn du Lust hast. Mach ein Video das den Bug zeigt ( Dein Video zeigt nur den UI Swap. Aber eben nicht das die Input Config tatsächlich Bit 4 schreibt)
ODER
Machen wir was aus auf Discord ( ist auch viel einfacher und direkter) ..... Share deinen Screen und stell mir das Problem nach. So das ich es sehen kann.
Gerne zeig ich dir meinen Screen und beweise so das es bei meinen Aufbau keinerlei Probleme gibt!

Und am Ende werden wir dann schlicht erkennen ob es Bug gibt oder das einer von uns beiden einen Fehler gemacht hat!