NEX6QGO Communication Pins?

[hourly]

I have a GL-iNet MiFi with communication pins (3.3v, RX, TX, GND) that I use with a microcontroller (Particle Photon) for issuing AT commands.

Example of band locking (param = "band", band = "800" for B12):

Code: Select all

serial->write("echo -e \"AT+QCFG=\\\"" + param + "\\\",0," + band + ",0\\r\\n\" > /dev/ttyUSB2 | cat /dev/ttyUSB2");

This is awesome and I'd really like to preserve this functionality when I swap the GL-iNet's EC-25AF in to the NEX6QGO-U. Using a cloud connected microcontroller allows me to tweak bands and look at signal info remotely, and also consume that data for webpages and mobile apps that I've built.

I noticed on "WiFiX WE826-T2 | WE826GO-U | Complete Build Instructions" that this image shows 4 pins (3.3v, RX, TX, GND) which makes me wonder:

1) Does the NEX6QGO have these pins (I can solder headers and whatever) and are they "hot"?
2) If they exist and are hot, would my command still work if I moved the microcontroller over to the NEX6QGO?
3) If they don't exist, I'm open to other ideas. A web api where I could login and get a token (if I must..), and then do HTTP post/get/whatever would suffice.

Bonus Q - what's the input voltage range for the NEX6QGO? I have a 12 volt lifepo4 battery that powers my current setup (though the MiFi is 5v) and would like to skip the questionable quality voltage regulators on Amazon if the router can tolerate 12.0v (really never drops that low, but that's low voltage disconnect on the battery's BMS) to 13.8v (when charge controller kicks off). The battery can supply a scary amount of current so there's no issue with anything being too wimpy. I would certainly fuse the input with the smallest 12v fuse I can find (5 amp?)

Thanks for any info!

Photo of connections on either a WE826 or 826GO circled in red

[Didneywhorl]

Those pins are hot and I myself believe they will work for you as you have in the glinet. You'll just have to clear the solder plugs so you can move the micro controller over there.

You should make a post on doing this, and maybe a full tutorial on how you did what you're doing for the remote monitoring. That'd be super cool.

[hourly]

You should make a post on doing this, and maybe a full tutorial on how you did what you're doing for the remote monitoring. That'd be super cool.

Sure will if I can figure it out. Obviously don't want to brick it. I'll try it out with my existing modem first since I know the commands are received as quoted in first post, correct syntax and all. I ended up ordering a slightly better modem (sierra wireless mc7411) to ultimately upgrade to for CA. I'll try that after I can confirm that I can communicate through these pins as desired with the EC25-AF.

Any idea on a web api? My code to do this over serial is absolute clown shoes, as indicated by the much trial and error snippet I quoted in first post, and even more convoluted when it comes to parsing data returned over serial in its weird / inexistent structure. I'd assume web api could return something tidy, JSON formatted or whatever:

{
"rssi": 0,
"rsrp": 0,
}

Had a raspberry pi doing this over the gl-inet web api but that was a little much to migrate to a microcontroller at the time. I think pepwave has an api too.

[hourly]

In case anyone is trying to do some quirky crap like this, here are my findings after tinkering with it for a few minutes:

I wired up my microcontroller the same as it was to my GL-iNet MiFi. That is, NEX6QGO ground to microcontroller ground, NEX6QGO TX to microcontroller RX, NEX6QGO RX to microcontroller TX.

Was hoping to luck out with it just working, but sadly that's not the case. With my microcontroller's program executing as it did before, I'm not getting back values for what I ask it via AT command sent via serial, and the modem Debug console on the WiFiX frequently shows the following only when the microcontroller is powered on and intermittently sending an AT command, like AT+CSQ (for something basic):

Code: Select all

/dev/ttyUSB2 
TIMEOUT ERROR
TIMEOUT ERROR
TIMEOUT ERROR

Without the microcontroller sending its intermittent AT command, this does not appear. My microcontroller code periodically executes like every 30 seconds, and frees up the serial port after reading a response to the end (ex: serial->readBytesUntil('\n', routerData, 120);) but I don't think I'm ever getting the new line character, so I never free up the serial port. This probably explains the constant TIMEOUT ERROR in the modem debug console when I'm actually trying to send commands.

I removed all of my code that's actually sending AT commands and decided to just log data from these router pins. And to my surprise, I was reading data without any effort. The same data that comes back in the WiFiX modem debug console. For comparison, the GL-iNet MiFi doesn't say anything unless it's sent an AT command.

So what I'd assume is that the WiFiX firmware is constantly polling data from ttyUSB2, and me sending my AT commands to ttyUSB2 (see quoted code snippet in first post) is clashing.

One thing I haven't figured out how to do that was easy on the mifi, is sending AT commands SSH'd in to the router. The same commands that work on the MiFi just result in debug information being printed in my terminal, but it's like the command never finishes or something because I'm not able to enter any additional text.. it just leaves a hanging [].

Theorizing, but maybe the command (again reference snippet in my first post) isn't complete. As in, lacks something at the end (a line break or something) to state that the command has been entered to completion. It's bizarre that this would work fine on the GL-iNet MiFi though.

[Didneywhorl]

This would be a perfect topic interjection here: https://forums.whirlpool.net.au/thread/ ... =-1#bottom

report back and tell us what they say. Link Dairyman to here if you want. I bet they could get you up and running, or atleast in the right direction.

The Goldenorb/WiFiX firmware does in fact constantly poll the modem with AT commands. You can reduce this to once a minute in the modem->network status screen, for signal information polling. (Bottom of the page)