Sorry, no solution for your problems, but:
-
Your first screenshot shows one
EV_JOIN_FAILEDin the device’s log, which is not accounted for in the screenshot of TTN Console. Did you see earlier join attempts before 14:41:25 then? If so, then I guess theEV_JOINEDrefers to the (re)try of 14:41:25, which sends the Join Request at 904.6 SF8 and then apparently successfully gets the Join Accept on 923.9 SF7. So, apparently that’s okay for the US frequency plan. (If you did not see an earlier Join Request, then maybe no gateway received it; I guess the successful one then still refers to what the screenshots show.) -
The third screenshot shows downlinks in TTN Console, so I guess the uplinks are confirmed uplinks? (You should not send every uplink as a confirmed uplink.) Then the next uplink is not listed as a retry (I’m sure the frame counters will have increased as well.) So apparently the downlink for the ACK is received as well.
-
The third screenshot also shows that for a 904.6 SF8 uplink, the 15:15:28 downlink is using 923.3 SF12, but the 15:25:30 downlink uses 923.9 SF7? Maybe one is in RX1 and the other in RX2. But if not, then how would a node know at which frequency to listen?
I find https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928 hard to understand; maybe you should confirm that it is complete and correct (like: what is used for RX2?), and that the device is allowed to use 904.6 SF8 (like: what should be used for downlinks then?). Not my cup of tea, but see also hybrid mode for US 8 channel gateways.
And though downlinks work (for otherwise it would never join), maybe it does not always work? See LMIC_setClockError. But regardless downlinks: once the join succeeded (which needs downlinks too), uplinks should show of course, even without downlinks…