My GPS receiver won't lock with the built-in antenna; I connected it to my Pixel phone USB port, started up Droid Term, and immediately saw the NMEA strings - good. However, no fix, just a lot of commas. So then I plugged in my external antenna/LNA and almost immediately got a fix. My board has a blank component location in the second spot from the U.FL connector - if I understand correctly, this is where the capacitor that needs to be removed was and is thus already removed.

Certainly not useful without a remote antenna - makes me think the built-in antenna is not functioning correctly.

@Pierre-Rossinès doing bit-banged SPI I/O would mean rebuilding the firmware image anyway, so you might as well just build the firmware with the patch (which is what I did). I'm building LEDE trunk with the addition of the Onion feed; the one real trick is to include the RAlink wifi driver from the onion feed and deselect all of the LEDE trunk wifi drivers. I can send you my SPI patch (derived from berniwa's patch and similar to @WereCatf) and .config file if you're interested.

@WereCatf I generated my own build (LEDE + Onion feed), incorporated berniwa's patch to spi-mt7621, and am pleased to report it's working for me so far (testing with both spi-test and pyOnionSpi). My SPI slave target is an Atmel ATmega1284P and I'm validating the behavior in the ATmega using a JTAG debugger.

I also flashed an O2+ with your provided image, and verified it with spi-tool. Of course, both of our patches include this warning:

             if (t->tx_buf && t->rx_buf) {
                    printk(KERN_ERR
                        "The MT7621-SPI does not support full"
                        " bidirectional SPI, only doing TX!");
            }

which generates arguably gratuitous chatter and probably ought to be removed (I'm removing it from my version of the patch).

I also validated larger than 16-byte transfers work correctly (I tested writes, since my slave device is currently very simple and doesn't talk back yet).

Pending a bit more testing, this patch seems like it ought to back upstream - would you consider doing the PR?

Thanks for the help!

@Brice-Parent I've got a patch that I apply in my own build; I suppose I could do a PR for it into the Onion repo, though I think it really should go upstream into LEDE/OpenWRT. Before doing a PR for that, I need to confirm that this issue is present in all MT7621-type SPI peripherals (not just in the MT7688 used in the Omega2) because it would patch all of them. Given that actual full-duplex operation is not possible with the patch, it is potentially a regression if there's a flavor of MT7621 SPI that actually does work (though I suspect that's not the case)

@Douglas-Kryder the other thing I did that may be notable, after desoldering the antenna from the PCB, is clearing excess solder from the antenna left over from when it was originally soldered to the PCB. In particular, one corner of the LNA shield (on the bottom of the antenna) is cut-away, but when it was soldered to the PCB, this corner was filled with solder and shorted to a pad/via on the LNA board. I cleared that on all of my 3 GPS Exps as part of the R&R and did not re-fill it when re-mounting the antenna. Given the shield is cut-away there, I believe it's not meant to short to the pad and this may be deafening the LNA.

@Dana-Myers114 I may have had a breakthrough with the GPS sensitivity issue. In the course of tinkering with my GPS receivers (removing the antennas, inspecting them, etc.) I found that sensitivity appears to be restored if you re-route the coax pigtail from the antenna so that it's not over the PCB:

This appears to reliably fix every one of my 3 GPS EXPs. I did desolder/resolver the antenna in each case before discovering this, but I don't think that's necessary - I think you may be able to fix your GPS by removing the pigtail from the U.FL connector on the PCB, re-route it, and replace it on the U.FL.

If you can try this and report back, I'm curious to hear how it works for you.

(I think this has to do with the cable/connector being too close to the input component on the PCB but that's speculation).

Dana

@WereCatf yeah I suppose one could install it and it might even work

@WereCatf the only SPI package in b160:

unless I'm mistaken.

I suppose one could install it with opkg.

My GPS receiver won't lock with the built-in antenna; I connected it to my Pixel phone USB port, started up Droid Term, and immediately saw the NMEA strings - good. However, no fix, just a lot of commas. So then I plugged in my external antenna/LNA and almost immediately got a fix. My board has a blank component location in the second spot from the U.FL connector - if I understand correctly, this is where the capacitor that needs to be removed was and is thus already removed.

Certainly not useful without a remote antenna - makes me think the built-in antenna is not functioning correctly.

@Pierre-Rossinès doing bit-banged SPI I/O would mean rebuilding the firmware image anyway, so you might as well just build the firmware with the patch (which is what I did). I'm building LEDE trunk with the addition of the Onion feed; the one real trick is to include the RAlink wifi driver from the onion feed and deselect all of the LEDE trunk wifi drivers. I can send you my SPI patch (derived from berniwa's patch and similar to @WereCatf) and .config file if you're interested.

@WereCatf presumably you've already confirmed the clock phase and polarity requirements of the display and that the MT7688 SPI is correctly configured? Are the other SBCs running the same bits (other than the SPI driver)?

@at there are bugs in the SPI support - I suggest looking at this forum thread for background:

https://community.onion.io/topic/1560/spi-pins-for-the-omega2/30

The summary answer is: you probably should try @WereCatf 's firmware image.

(However, I expect spi-tool write 0x12 0x42 to correctly send 0x12 0x42 to the device, so it might be something else)

@WereCatf I generated my own build (LEDE + Onion feed), incorporated berniwa's patch to spi-mt7621, and am pleased to report it's working for me so far (testing with both spi-test and pyOnionSpi). My SPI slave target is an Atmel ATmega1284P and I'm validating the behavior in the ATmega using a JTAG debugger.

I also flashed an O2+ with your provided image, and verified it with spi-tool. Of course, both of our patches include this warning:

             if (t->tx_buf && t->rx_buf) {
                    printk(KERN_ERR
                        "The MT7621-SPI does not support full"
                        " bidirectional SPI, only doing TX!");
            }

which generates arguably gratuitous chatter and probably ought to be removed (I'm removing it from my version of the patch).

I also validated larger than 16-byte transfers work correctly (I tested writes, since my slave device is currently very simple and doesn't talk back yet).

Pending a bit more testing, this patch seems like it ought to back upstream - would you consider doing the PR?

Thanks for the help!