G4lile0 / tinyGS

📡 Open Ground Station Network 🛰
GNU General Public License v3.0
923 stars 177 forks source link

T-Beam V1.1 433MHz Doesntwork as Tbeam but as TTGOv2 #115

Open fr4sw opened 3 years ago

fr4sw commented 3 years ago

Quite all in the title : T-Beam V1.1 433MHz Doesn'twork as T-beam but as TTGOv2 Using uploader, work fine until Wifi link As T-Beam : The T-beam is unable to link the Wifi network and ask to get back to 192.168.4.1, and then the admin password answer no more work (but seems runing), needing to use uploader again As TTGOv2 : works fine, no problem like above

hope this can help, don't hesitate if you need some experiment or point place (file/function) where I can try changes. 73

sfjuocekr commented 2 years ago

v1.1 works for me as well with TTGO v2 and the TBEAM v1.0! With the other ones you get the "button pressed" situation.

I also saw in the PR's that the v1.1 board should be added soonish hopefully.

MikeJaras commented 2 years ago

[edit: It looked like it worked but no packets received so far...] I used this home-made template with T-Beam v1.1 and oled. Works fine after power reset, the restart from web-config didn't work.

{"name":"T-beam v1.1 + oled","aADDR":60,"oSDA":21,"oSCL":22,"pBut":38,"led":14,"radio":1,"lNSS":18,"lDIO0":26,"lRST":23,"lMISO":19,"lMOSI":27,"lSCK":5,"lTCXOV":0.0}
rwcts commented 2 years ago

I have a Tbeam v1.1 with OLED and it is working. I had to set the "board type" to "T-BEAM V1.0 + OLED" and that worked. Setting the unit to the proper board type which was "433Mhz T-BEAM +OLED" only briefly connected to wifi showed the connected screen but then reverted to the ap mode to configure the unit. Curious if you try this and it works for you?

MikeJaras commented 2 years ago

Well, I did try that but from what I remember there where some issues. So I tried a different route and built new code with vs-code and added the board in to the menu. I ended up with a T-beam on my roof that run for two weeks without receiving any packets. The t-beam I got is for the 868/915 mhz band and I tried it on both 868 and 433mhz with different antennas. So I ordered a different board and I received satellite packages directly, without crc-error. The new board was LILYGO TTGO LoRa32 V2.1 ESP32 433MHz. Station is SM0SML_433_II

cspacone commented 2 years ago

RWTCS: I have exactly the same results as you. Lilygo T-Beam see picture for board model, by SMA connector.

I'd love to help, but I'll need to study the template creation details. Not quite sure where to start there but reading the messages in Git seems to be a good start!

Also, not sure where the board pulls its TLE's from, where they are stored on the board and if they can be edited.

And lastly, it seems there is an LED for the UBlox GPS. I'd expect to see this blinking at 1PPS if the GPS had a lock.

I'd love to find a schematic for this board.

73, KD6OUB

LILYGO T-Beam V1 1

cspacone commented 2 years ago

So I found a schematic as well as some of .INO code (Ardunio IDE I'm guessing). Determined that the serial port is sending and listening on the USB connector (115200, 8,n,1) and fired up the board with the T-BEAM V1.0 + OLED code.

While watching with Putty I see the lines:

Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:10124 load:0x40080400,len:5828 entry 0x400806a8 00:03:34 TinyGS Version 2105260 - 2105260 00:03:34 ERROR: Your modem config is invalid. Resetting to default

After that, no display on the OLED. So I'm clearly on to something here regarding the modem setup commands being passed by the template.

More study...

73, KD6OUB

garethblower commented 2 years ago

I have a T.Beam v1.1 433MHz, and I cannot get it to connect to my WiFi AP. Its config AP comes up just fine, the OLED display works as expected, but whatever board type I try to configure, including the custom template above, it refuses to connect to my WiFi AP (and MQTT, obviously). Is there a debug mode over serial that might give some clues about what is going wrong?

garethblower commented 2 years ago

@cspacone - that begins to make sense now. If the modem config is invalid, it will drop back to "AP config" mode, which is why I don't see mine trying to connect to my WiFi AP. A difference for me, though, is that I never lose the display (which is one way I know it has reverted to "AP config" mode.) You're probably doing the same thing, but I'm going to go off and research the modem commands...

(G4MQR)

garethblower commented 2 years ago

I now realise that the modem commands may be OK - if the LoRa pin designations in the config are wrong, then when the modem config. commands are sent, no valid response will be received, which will probably result in the "Your modem config is invalid. Resetting to default" message. I need to look at the code to verify this.

garethblower commented 2 years ago

Well, looking at the schematic here, it would seem that the custom template above has all of the LoRa pin designations correct, so back to looking at the modem config.

garethblower commented 2 years ago

After a lot of head scratching, I couldn't find any problem with the config. above. I rebooted my WiFi AP, and the board was able to connect. It appears that the config. above is correct for my board, although I can't say for certain yet, as I am still using the rubber duck antenna and unsurprisingly have not received any packets so far. The real test will be when I get my ground plane antenna and LNA set up.

cspacone commented 2 years ago

I pulled the sticker off the loRA module and discovered that it is made by HDPTeK and is a model HPD 14A V1.2 and appears to incorporate a Semtech SX1278 transceiver. I have a copy of the Semtech datasheet covering this 1278 variant but I'm pretty sure this won't provide much in the way of enlightenment. Ping me if you want a copy of the 132 page document.

Here is a picture of the back of the module:

HDPTeK HPD14A V1 2 Layout

stephenmorton commented 2 years ago

Hi All, So, does anyone know the best dropdown in the list to select for this board (LILYGO TTGO T-Beam V1.1? I have tried TTGO V2, T-Beam V1.0 + OLED and they seem to work, however, I've not had any success receiving satellite data. I have a 5/8 70cm outside. Also, does anyone know what the LED's on the board mean. There is a red and blue LED close to the ctr of the board (Blue obviously indicated charging and the red LED close to it I think means GPS), however, there is another flashing red LED close to the GPS antenna socket. I am not sure what this does, I have not been able to find much info anywhere.

K4KDR commented 2 years ago

Schematics for a number of the T-Beam versions are at https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series#product-

... and the flashing red LED near the GPS antenna, while it can take a LONG time to activate, seems to indicate when the unit has acquired enough GPS data to have a valid position. The on-board antenna is so small that 15-20 minutes is not unusual. Of course if a better antenna is connected, the GPS lock might happen faster, you would think.

I don't use a T-Beam for tinyGS, but have several for other projects such as a weather station, LoRa-APRS tracker, & weather balloon radiosonde tracking.

Oh, and about half-way down this page, the function of the LEDs is mentioned on the ' Pin Schematic' drawing -> http://www.lilygo.cn/claprod_view.aspx?TypeId=62&Id=1281&FId=t28:62:28

-Scott, K4KDR

MikeJaras commented 2 years ago

I didn't succeed either with the T-beam and TinyGS. But I got the 868 mhz version and changed for a 433 mhz module. I also use the T-beam for other projects. But a changed the antenna for a Cirocomm 580 that I bought used. And that made a huge difference. Instead of waiting 10-20 minutes outdoors and sometimes without getting fix it now takes just minutes and works also indoors.

stephenmorton commented 2 years ago

Thanks for your replies MikeJaras and for the links K4KDR. I did a little more research and for anyone interested. As we know the blue LED indicated charging. The red LED near it, is driven by GP104 on the ESP32, so I guess it's just a status indicator. Mine stays solid red, might indicate I have a battery in or something (which I do). The flashing red LED near the GPS is as K4KDR pointed out and seems to simply be a GPS indicator. It points to a pin on the GPS chip called Time pulse, so I guess if it blinks, then it's indicating a time fix from GPS. Re getting the board to receive satellite, I used the "T-BEAM V1.0 + OLED" dropdown, and finally received my first satellite last night. So, that one seems to work. I am not sure if others will work equally, but I can say for certain that currently, that dropdown setting works on this board. Thanks for all your help guys, I'm off to play with my TTGO and TinyGS some more :-) Steve VK2TTG

cspacone commented 2 years ago

... and the flashing red LED near the GPS antenna, while it can take a LONG time to activate, seems to indicate when the unit has acquired enough GPS data to have a valid position. The on-board antenna is so small that 15-20 minutes is not unusual. Of course if a better antenna is connected, the GPS lock might happen faster, you would think. -Scott, K4KDR

The GPS finally locked once I took the board outside, I've been able to get locks using other GPS receivers while indoors so I made the mistaken assumption that this one should be able to do the same.

Lesson Learned...

For what it is worth I've managed to get the board running using the configuration I mentioned earlier. I have no earthly idea what I did different this time around but it 'seems' to make contact with MQTT and TinyGS website (see station KD6OUB).

Odd behaviour: The board seems to shut down when running on battery power. I plug it into the USB connection and look for the CHG light to come on and I don't see it.

I wonder if there is something in the T-BEAM V1.0 + OLED code that isn't enabling the charging portion of the power controller chip.

I've been looking around for someplace in the code that asserts this but I can't find anything.

Any ideas?

73, Chris, KD6OUB

MikeJaras commented 2 years ago

I don't think the charging is possible to affect since it's controlled by the AXP192. You got the schematics here.

cspacone commented 2 years ago

Not sure what you mean Mike. The AXP192 datasheet (https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/datasheet/core/AXP192_datasheet_en.pdf) is pretty clear about charging batteries and that this functionality can be controlled by TWSI (Two Wire Serial Interface), pins 1 and 2 (SCK, SDA).

A full link to the AXP192 details (http://www.x-powers.com/en.php/Info/product_detail/article_id/29) and links to technical documentation (login required), Note the X-Powers site is a pain in the ass to get documentation from.

But the foregoing not withstanding, somebody managed to set up the code to make the charge light active, at least under the Meshtastic firmware loaded to this very same board.

So in short, I disagree but I don't have the technical chops to wrangle the TinyGS code and implement it myself.

-Chris

MikeJaras commented 2 years ago

I just mean that the chance is slim that you disable the charging led when changing the board type from the dropdown. If the light is there with one board it should be there with an other. It's not like you config a different pin for the led.
I listed all the pins and added my own board to the dropdown. Then it worked kindof, but no packets received on 868 mhz. I should have set it up with a better antenna or used a LNA plus filter. Here is the list from the TinyGS code and mine is the last one. It worked fine when I used T-beam v1.1

MikeJaras commented 1 year ago

I restarted my 868 mhz project and now I got it to work. But the satellite station I receive is really far away. It is so far away that it looks faulty. If anyone wants to try it out I include the firmware for t-beam 1.1. The only change in it is the button config. The other ones are triggering a button press and goes to local mode. I used the normal firmware to get up and running and then updated the firmware with my version. Then choose "T-beam v1.1 + oled" from the menu. And have a look at the fantastic distance which I receive messages, most likely not correct. The station name is SM0SML_Enskede.

firmware.zip

mgrennan commented 1 year ago

Yup - Works good as a "433 Mhz TTGO LoRa 32 v2" as does "T-BEAM V1.0 + OLED"

Or at least... Connects to the INet router without failing into setup mode.

Nachtwind85 commented 1 month ago

Just to update this and add the newer syntax for the board template which works reasonably well for me: {"name": "T-beam v1.1 + oled", "aADDR": 60, "oSDA": 21, "oSCL": 22, "oRST": 0, "pBut": 38, "led": 14, "radio": 1, "lNSS": 18, "lDIO0": 26, "lDIO1": 0, "lBUSSY": 0, "lRST": 23, "lMISO": 19, "lMOSI": 27, "lSCK": 5, "lTCXOV": 0.0}

name: "T-beam v1.1 + oled" - The name of the board. aADDR: 60 (0x3C in decimal) - The I2C address of the OLED display. oSDA: 21 - The SDA pin of the OLED display. oSCL: 22 - The SCL pin of the OLED display. oRST: 0 - The reset pin of the OLED display. pBut: 38 - The GPIO pin used for the user button. led: 14 - The GPIO pin used for the main board indicator LED. radio: 1 - The type of radio module used by the board (1 for sx127x). lNSS: 18 - The NSS pin of the LoRa module. lDIO0: 26 - The DIO0 pin of the LoRa module. lDIO1: 0 - The DIO1 pin of the LoRa module. lBUSSY: 0 - The BUSY pin of the LoRa module. lRST: 23 - The reset pin of the LoRa module. lMISO: 19 - The MISO pin of the SPI bus. lMOSI: 27 - The MOSI pin of the SPI bus. lSCK: 5 - The SCK pin of the SPI bus. lTCXOV: 0.0f - The TCXO voltage (only used for SX126X modules).