Thanks. I’ll also do a test tomorrow. Perhaps I broke something. 
2 Likes
@geeksville check out PR #579. I was in this area last night and may have fixed the problem described by @IZ1IVA
2 Likes
I see a different problem on the lora32 board. Can’t quite pin it down.
On first power-up, everything works great. Often (>75% of the time) after pressing the reset button, then screen doesn’t turn back on.
The odd thing is the screen will always work on first power up. I saw something similar in bug #491 but the symptoms are different with the recent firmwares.
When that happens, the debug log doesn’t show the usual “Turning on screen” message. I have three of the boards on hand, will try it out on others to make sure that it’s not a lose connection or something.
1 Like
Hmm. Can you try a test of lying and just setting “have_screen” (I forget the name of the bool)? Perhaps our i2c loop that scans all addresses has a problem? Or if reset at a bad time, the first i2c transaction to the display gets missed. (Alas I don’t have one of these boards with me in Taiwan) 
Sure, I’ll tell have_screen that it works when I know it doesn’t work and anyone who says it really doesn’t work is fake news.
The i2c loop and have_screen. Will check it out after dinner.
1 Like
Thanks for the pointer to scan I2Cdevice.
Looks like the screen on one device (it doesn’t happen to others) moves the I2C address from 0x3c to 0x3d on reset. I bet this is a bad oled. I don’t see i2c address resistors on the schematic, so I’d don’t think I can easily fix this by reworking the PCB. I inspected the cable connector under the microscope , other than far too much flux I don’t see any cold joints.
Oh well, I’ll label this as defective and maybe it’ll become a relay.
1 Like
Hmm - seems okay on my tbeams.
@IZ1IVA one more question. For your nodes did you set is_low_power or --set-router? Doing either of those things will let the CPU go to sleep even if it has USB power (the lora radio stays on of course).
Can you paste the results of “meshtastic --info”?
I’ve tried both --set-router and --unset-router, but the end result is the same.
A few minutes ago I’ve flashed 1.1.18 and the meshtastic utility couldn’t talk to the T-Beam anymore. So I’ve re-flashed 1.1.23 and things went back to normal i.e. meshtastic could talk to the board, but only for a short while.
1 Like
Hmm, can you post the results of meshtastic --info.
Sure! In this case, router mode is off:
Connected to radio
my_node_num: 476282860
has_gps: true
num_channels: 10
region: “1.0-EU865”
hw_model: “tbeam”
firmware_version: “1.1.23”
packet_id_bits: 32
current_packet_id: 400989763
node_num_bits: 32
message_timeout_msec: 300000
min_app_version: 20120
preferences {
ls_secs: 300
region: EU865
fixed_position: true
}
channel_settings {
modem_config: Bw125Cr48Sf4096
psk: “\001”
}
thanks! I’ve managed to repro the problem. I’m working on a thing for @syed now, but I’ll work on this tomorrow.
1 Like
1 Like
Does this problem still occur for anyone with a TBEAM 1.0 if using 1.1.30 or later? I can’t repro it.
I can’t either, appears to be fixed for good, thanks!
2 Likes
import meshtastic
from pubsub import pub
import threading
import time
from time import sleep
import datetime
def onReceive(packet, interface): # called when a packet arrives
print(f"Received: {packet}")
def onConnection(interface, topic=pub.AUTO_TOPIC): # called when we (re)connect to the radio
print ("starting...")
rt = RepeatedTimer(30, sendText) # no need of rt.start()
def sendText(): # called every x seconds
currTime = datetime.datetime.now().strftime("%H:%M:%S")
interface.sendText(currTime)
print("Message sent: " + currTime)
pub.subscribe(onReceive, "meshtastic.receive")
pub.subscribe(onConnection, "meshtastic.connection.established")
# By default will try to find a meshtastic device, otherwise provide a device path like /dev/ttyUSB0
interface = meshtastic.SerialInterface()
class RepeatedTimer(object): # Timer helper class
def __init__(self, interval, function, *args, **kwargs):
self._timer = None
self.interval = interval
self.function = function
self.args = args
self.kwargs = kwargs
self.is_running = False
self.next_call = time.time()
self.start()
def _run(self):
self.is_running = False
self.start()
self.function(*self.args, **self.kwargs)
def start(self):
if not self.is_running:
self.next_call += self.interval
self._timer = threading.Timer(self.next_call - time.time(), self._run)
self._timer.start()
self.is_running = True
@thepoweroftwo Can you please tell me, can I pass an argument through sendText(argument) in the line rt = RepeatedTimer(30, sendText)?
-MSGINPUT- = 'your sting here'
interface = meshtastic.SerialInterface()
interface.sendText(values['-MSGINPUT-'])
~~~I am not talking about individual function calling, I am talking about the thread.
Why do you want to pass an argument to the sendText() function?
To answer the question, yes, you can pass arguments to the sendText function by writing:
rt = RepeatedTimer(30, sendText, argument1)
If you want to pass multiple arguments, I think you must pass a List (Python Lists) of parameters. I’m not sure though.
Let me know if it works.
1 Like
@thepoweroftwo Actually I am trying to read text data from a file line by line and pass that in sendText that as an argument. Your solution is working but same is not reflecting on my desktop application pythongui1.py code. I am sharing my github repo with you, please do the threading properly, so that the program reads one line after the other and sends it and that reflects on the pythonGUI app, and when the file reaches it’s end, it stops and terminate the connection.
https://github.com/Arijitdutta19910601/Meshtastic-Interface-GUI
You’ll require pyhthongui1.py and myFile.txt from the repo
P.S: Please focus on the randchar(), randchar2() and timer() method in the program and also I made some changes in the RepeatedTimer class to stop the communication when the file reading ends. Please look to it carefully.