Fix issue with miss-identification of Falcon boards in FPP connect.

[cybercop23]

Falcon.cpp has ModelDecode as below, which is correct based on what ip/status.xml returns (ie:

130

for F16V5. However FPPConnect was looking at the 88-91 range vs 80-93 to set up a Falcon V4or V5 board. case 128: model = 16; version = 4; break; case 129: model = 48; version = 4; break; case 130: model = 16; version = 5; break; case 131: model = 48; version = 5; break;

[cybercop23]

@JohnLarsonELF FYI...

[dkulp]

With this change, won't the various V2's will be identified as FPP connect capable. The typeId should be coming from the discovery packet which should be using the properly assigned ID's:

           - 0x80 - Unknown Falcon Controller
           - 0x81 - F16v2-B
           - 0x82 - F4v2-64M
           - 0x83 - F16v2 (Red)
           - 0x84 - F4v2 (Red)
           - 0x85 - F16v3
           - 0x86 - F4v3
           - 0x87 - F48
           - 0x88 - F16v4
           - 0x89 - F48v4

[cybercop23]

But those are not the right IDs based on Falcon.cpp and what gets returned by the discovery process with IP/status.xml

An F16/V5 returns 130 which is 0x82.

[computergeek1507]

I think xLights needs to map the id of the falcon status page to the FPP id

[dkulp]

On my F16v5, the discovery is setting the type to 0x90 which is correct:

[dkulp]

And when in Remote mode, it properly appears in the list:

[computergeek1507]

Is that the results from a FPPs Multisync results or directly from the controller. And is it over Ethernet or WiFi. We have seen different results over different interfaces.

[cybercop23]

In John's case, we can get it to show up on FPP but never in FPP Connect. Ctrl is defined in xlights, Active, has all right info, and it is wired.

@dkulp what do you get from the ctrl status.xml 192.168.3.220/status.xml

[dkulp]

Would definitely be ethernet. I haven't tried to put a Falcon on wifi. That's just the result of hitting Tools -> FPP Connect which would likely be first initiated via either the Ping packet or from an FPP multi sync page.

[dkulp]

Most likely, somewhere around line 577 of Discovery.cpp, if the cd->typeId == 0 then it should map the Falcon model/version combo to the appropriate typeId. I don't see it setting the typeId there so if it's not discovered via the normal multicast Ping packets, it's likely not being set and is defaulting to 0.

[dkulp]

Also, is it NOT in DDP/e1.31/ZCPP modes? That's important as well.

[cybercop23]

Also, is it NOT in DDP/e1.31/ZCPP modes? That's important as well.

No, they are in Remote mode with an SD card inserted, so we can upload sparse fseq data.