OMG - you are right Eugene. I just did a test. For the last couple of weeks all ‘official’ builds have been using the US frequencies. Builds made locally through the IDE were fine. Fixing now and putting out a fix.
1 Like
hmm - probably also explains this bug (which I hadn’t looked into yet)
I waiting for bin’s, because failed with PlatformIO project on Win10 (VS Code does not find Libraries). I think, I have tried everything. Creating new projects without any issues.
@Eugene Yes sure, https://drive.google.com/open?id=1HsiRqXb5lwMf7A3iUVZHCmOATKfLwElf
@geeksville that bug I raised is only cosmetic for me the actual frequency is correct for my local build
2 Likes
Tried the new firmware and got a lock between devices in under a minute. I was able to send coordinates between phones but had intermittent texting. Some times it works but not always. I’m not sure if its a bluetooth distance thing as it seemed more consistant when the phone and device were within a meter.
hi Killeramoeba, (maybe my reply comes too late)
In the T-Beam, TTGO puts a sticker on their LoRa modules, indicating the frequency, but if you want to be really sure, you should physically check if the LoRa IC is SX 1278 (433 MHz) or 1276 (868-915 MHz but can also function on 433 MHz with the right antenna matching components). The IC and all antenna matching components are inside the metal shielding cover. With a heatgun, it is easy to unsolder this cover to check, but this would void your warranty.
As T-beam’s come with their matching antenna for the board’s frequency, and you think your board came with the wrong label, it may also be that it came with an 868/915 antenna and not with a 433 one. Did you try with any familiar antenna’s you know the frequency range of ?
Yeah, an rtl-sdr might show what your radio is outputting, good idea Scott !
I should scope the included antennas. They should be fine even if they’re meant for 868-915 MHz as its roughly a half wave but obviously you’d lose some gain since your moving down in frequency. Nice thing with 433 is its 70cm band which have a ton of options.
I’m also having a problem with the GPS reporting at “bad” on a T-Beam v1.0. Code works fine on one T-Beam but is erroring on a second.
These devices just arrived so I’m trying to diagnose if it’s a hardware issue. Including the logs from a reboot of the bad device.
booted, wake cause 0 (boot count 1), reset_reason=reset
I2C device found at address 0x34
axp192 PMU found
I2C device found at address 0x3c
ssd1306 display found
done
Meshtastic swver=0.6.3, hwver=1.0-US
chip id detect 0x3
Detect CHIP :AXP192
OUTPUT Register 0x5f
AXP192 Begin PASS
DCDC1: ENABLE
DCDC2: ENABLE
LDO2: ENABLE
LDO3: ENABLE
DCDC3: ENABLE
Exten: ENABLE
----------------------------------------
DCDC1: ENABLE
DCDC2: ENABLE
LDO2: ENABLE
LDO3: ENABLE
DCDC3: ENABLE
Exten: ENABLE
SRC REG:0xc4
Charging enable is enable
Charging target-voltage : 0x2
end when the charge current is lower than 10% of the set value
Charge current : 700.00 mA
enable [0x40]val:0xdc
enable [0x41]val:0xff
enable [0x42]val:0x3b
Turning on screen
Read RTC time as 1 (cur millis 1529) valid=0
Connected to UBLOX GPS successfully
RadioConfig reset!
Loading saved preferences
Warn: devicestate is old, discarding
NODENUM=0x28, dbsize=1
Starting meshradio init...
Set radio: name=Default, config=3, ch=6, txpower=23
LORA init result 0
sending owner !2462abdddb28/Unknown db28/?28
Update DB node 0x28, rx_time=0
old user !2462abdddb28/Unknown db28/?28
updating changed=0 user !2462abdddb28/Unknown db28/?28
Adding broadcast record for fr=0x28,to=0xff,id=74
enqueuing for send on mesh fr=0x28,to=0xff,id=74 (txGood=0,rxGood=0,rxBad=0)
Screen: Started...
fix type 3
Starting low level send from=0x28, id=74!
Completed sending to=0xff, id=74
Ignoring invalid GPS time
Transition powerFSM transition=boot timeout, from=BOOT to=ON
Setting bluetooth enable=1
Pre BT: 169408 heap size
Starting bluetooth
*** Mesh service:
showing standard frames
fix type 3
authenticated and connected to phone
Trigger powerFSM 9
Trigger powerFSM 9
pbread from ea9f3f82-8dc4-4733-9452-1f6da28892a2 returns 28 bytes
showing standard frames
Reading radio config, sdsecs 31536000
Trigger powerFSM 9
pbread from b56786c8-839a-44a1-b98e-a1724c4a0262 returns 62 bytes
Trigger powerFSM 9
Reset nodeinfo read pointer
Trigger powerFSM 9
Sending nodeinfo: num=0x28, lastseen=0, id=!2462abdddb28, name=Unknown db28
Trigger powerFSM 9
Done sending nodeinfos
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
fix type 3
fix type 3
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
Setting RTC 316387994 secs
Read RTC time as 316387994 (cur millis 90252) valid=1
fix type 3
fix type 3
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
fix type 3
fix type 3
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
new gps pos lat=0.000000, lon=0.000000, alt=0
fix type 3
Ignoring invalid GPS time
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
fix type 3
fix type 3
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
new gps pos lat=0.000000, lon=0.000000, alt=0
fix type 3
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
Transition powerFSM transition=Screen-on timeout, from=ON to=DARK
Turning off screen
fix type 3
fix type 3
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
Ignoring invalid GPS time
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
fix type 3
Ignoring invalid GPS time
fix type 3
fix type 3
processUBX: counter hit MAX_PAYLOAD_SIZE
new gps pos lat=0.000000, lon=0.000000, alt=0
fix type 3
fix type 3
fix type 3
Transition powerFSM transition=Bluetooth timeout, from=DARK to=LS
lsEnter begin, ls_secs=3600
lsEnter end
lsIdle begin ls_secs=3600
Setting bluetooth enable=0
authenticated and connected to phone
Shutdown BT: 166288 heap size
interesting. Can you try leaving it outside for a few minutes to see if that allows it to build an almanac?
I’m guessing the red pulse per second LED isn’t flashing once a second? Quite likely you don’t have a good signal as the supplied antenna seems flaky at best. Like geeksville said, it can take a fair while of good signal to get a fix the first time you power up a GPS.
Could we help devices, to build their almanacs, by assisting them with the data updated by the app trough bluetooth/USB (A-GPS)?
Leaving it outside fixed the problem. I know this is a new project but as a future addition, would love to see an additional screen that displays when there is an error showing more info about the problem and maybe helpful suggestions.
In the case of the GPS, a screen like:
GPS not connected
Signal too low
Try leaving outside for a couple minutes until red led flashes
The prebuilt almanacs would be awesome if possible as well, not sure if it’s feasible with the GPS possibly requiring area specific data.
3 Likes
I dont think these have access to Assisted GPS like mobile phones, cold start in a new area takes a while, the antennas aren’t that great, I found that sticking it to the side of the 18650 holder near the LoRa antenna seemed to work, but that could be a placebo. Others in the TTN LoRaWAN groups have upgraded their antennas to good effect. Subsequent starts should be better, my deskis near a window and both my units work well there.
“The NEOM8N, NEO-M8Q, and NEO-M8M modules support the u-blox AssistNow Online and AssistNow Offline A-GNSS services, support AssistNow Autonomous, and are OMA SUPL compliant.”
“The orbit data can be stored in the GNSS receiver’s SQI flash memory or alternatively within the memory of the application processor. The function requires no connectivity at system start-up, enabling a position fix within seconds, even when no network is available. AssistNow Offline offers augmentation for up to 35 days.”
My mistake (double post).