I have made my own 6 digit 7segment displays. They are based on the MAX7219 chip (bought in China π ) . They have been working for weeks without any issue. Then the other day they started to behaviour strange. I have 2 displays connected on the same interface and they are connected to active and stdby radio frequencies. Besides that I have connected 2 encoders to control the digits. When I power on the Arduino Mega board and connect MobiFlight both displays show 123.850. Perfect! When I then start to rotate the encoder the number starts to look strange. (e.g. 248.7 .5) When I rotate 2 more "clicks" on the encoder the number jumps back to 124.900. - and so on. Anybody have any idea of what is going on. I have also tried to change the frequency from within the simulator and still the displays be strange.
#strange behaviour on 7-segment displays
1 messages Β· Page 1 of 1 (latest)
how are you feeding power to the displays/max chips?
Hi...
At first you should find out if the used data is correct.
Display must show all time the same value as Mobiflight connecter ask it to do.
So check if the right collumn "Output Value" of the Config ( Mobiflight Output Tab) is correct.
If there is 123890 e.g. but Display show something strange then we get a MAX Problem
If there is also a wrong value in MF then the Config logic is fault.
They are powered via the USB port on the arduino and through the 5V connectors on the pin headers. Do you think I need a separate power supply for this?
no, but make sure you have a direct 5V to each of the MAX7219s
All this looks OK
So you mean I should not supply them from the Arduino, right?
you can, but make sure you have 5v running to the 5v of each max chip and you aren't daisy chaining the power
because I tried to connect a single one but still got the issue
The arduino is a China copy and the display board is some boards I produced myself. I copied the layout from a standard. And as I said they did work fine until a couple of weeks ago
I'm not sure then sorry π¦
@lone pond and @near sun I found the bug. Data from the flight simulator has changed. Previously the flightsim value was to be divided by 10,000. This have changed for the Fenix A320 at least. So now you have to divide by 1,000 instead π thnks for your inputs.
ah nice!
hhhm. Strange. Does Fenix use own COM`s ??
Nearly all Aircrafts i work with in the past use Stock Sim Frequency
And here you not need something like 10000 or 1000 You simply change the unit type
Just for interest .... Can you share the Code for e.g. COM1 Stby.... so we see what you do there ?
Could this have been caused by the integer -> float change in MobiFlight? (sim data was read as integer before, now it is float decimal numbers), depending on what kind of calculations you did before those might need to be changed..?
This is what now works for me. Before the Transform was $/10000
If we talk about fenix.... Why using FSUIPC . Simply use SimConnect FS2020 Outputs!
There you can define what value you like ( unit typ) e.g. in hz, khz or Mhz.
And also Tuomas is right.... This is COM in hz .... So 123,456 is 123456000
$/10000 in the past occur in 12345,6 ( What is truncate 12345) Now its 12345,6 and can be a problem.
But at the and.... There is no need to make a divide here ! (Expect for LCD)
And finally if we use FS2020 Simconnect we can directly read 123456 or 123,456 whatever we need.
Summary.... $/10000 is wrong and was also wrong before !
@near sun You must likely have more experience in using mobiflight than I do, so you are probably right. I can just say that I changed from 10000 to 1000, so I must have made another mistake elsewhere that I cannot figure out. The reason for using FSUIPC was I was not able to make the 7 segment display to update while I was turning the knob on the real world encoder. Maybe you know an entry in simConnect fs2020 were this works that I have not tried out π again thank you for your feedback
@near sun just tried the simconnect. is is working as you described π
The data from Simconnect (e.g. Com1 Stby frequency) is 100% the same.
Also FSUIPC just read it from Simconnect internal !
Hard explaned.... Every single data from FSUIPC is also readable via SimConnect !
π
Maybe you can help with another one. The Altitude set point from the autopilot on the Fenix A320. which variable is that?
I not use Fenix.... Here you need to talk to the guys who build the events (Jaime i expect).
The "AP Altitude" is pretty sure a special fenix event... Cause thats a internal Value that is not read by FSUIPC.
The Stuff FSUIPC read is the "stock" data.... So mostly all things for the Aircrafts included in the Sim.
Fenix is a AddOn.
It have own data.
Except some things like mostly the Radio. Or the Parking Brake.
There are simply "some" basic Elements that also AddOns use..... AP Alt is not one of them !