Hi @mikemx55 Looks like that page has been moved to a different section, here's the new link: https://docs.pycom.io/gettingstarted/programming/repl/telnet

Could you use a battery and inductively charge the battery?

@tuftec, yes you are correct, the machine.deepsleep() machine.remaining_sleep_time() and pin_deepsleep_wakeup() functions all work fine. I have isolated my problem was with the LoRa publishing code. When I commented out the lora_publish in my code below everything worked fine. The bug must be something to do with nvram functions i am using in my lora_publish function. Perhaps this bug is best published in a new thread. Thanks for the comment. Code published to allow others a quick start! import machine import utime from machine import Pin import pycom import config #user defined #import LoRa_publish #user defined rst=machine.reset_cause() if rst != 3: # if not woken from deepsleep utime.sleep(10) #to allow ctrl+C pycom.nvs_set('counter', 0) #button = Pin('P23', mode = Pin.IN, pull = Pin.PULL_UP) machine.pin_deepsleep_wakeup(pins = ['P23'], mode = machine.WAKEUP_ALL_LOW, enable_pull = True) machine.deepsleep(60000) else: if (machine.wake_reason()[0])==1: #pin wakeup total_count = pycom.nvs_get('counter') +1 pycom.nvs_set('counter', total_count) print('remaining deepsleep time is {}'.format(machine.remaining_sleep_time())) machine.pin_deepsleep_wakeup(pins = ['P23'], mode = machine.WAKEUP_ALL_LOW, enable_pull = True) machine.deepsleep(machine.remaining_sleep_time()) elif (machine.wake_reason()[0])==2: #RTC timer complete print('timer completed') total_count = pycom.nvs_get('counter') print('counted {} button presses'.format(total_count)) #LoRa_publish.publish(total_count) #INT published to TTN pycom.nvs_set('counter', 0) machine.pin_deepsleep_wakeup(pins = ['P23'], mode = machine.WAKEUP_ALL_LOW, enable_pull = True) machine.deepsleep(60000) #this does not restart a new interval!!

@burgeh It depends a lot, but generally (and specifically in your case), no. Listening for LoRa packets consumes power. The LoRa chip on the LoPy 4 (SX1276) uses 10 mA when listening, and the rest of the LoPy uses about 50 mA average. You could probably reduce the ESP32 power draw with some more or less advanced uses of sleep (i.e. not out of the box), but we're still talking tens of mA, compared to about 10-20 µA in deep sleep. This means that if you are listening all the time, even a relatively large 2500 mAh battery will only last a few days. This may or may not be a problem for you depending on the use case (mains powered, enormous battery, solar powered, ability to recharge/change battery often...), but this is usually not the kind of use case for LoRa, and from your question "more efficient power wise", it's clearly not what you are looking for. So it usually remains more power efficient to deep sleep, wake up on whatever event (time, pin change...), send the frame, check for an ACK, retry if no ACK was received, and go back to deep sleep. Note also that there are many other reasons than just another one of your nodes sending data that could trigger a frame being lost. The frequency bands are shared, so there will be other devices using them, and you will end up with collisions and other forms of noise even if you control when all of your devices send.

Hi @nobo23 Are you trying to connect multiple sensors to the WiPy and communicate with them via Bluetooth? Connecting multiple BLE nodes to the WiPy is possible. You can find our BLE examples here. Hope this helps, let me know if you have any questions!

@sympatron Probably, we'll release a stable version at the end of this week, not completely sure. Also, as these Mesh features (Border Router) are in progress, not sure when to commit that I'll finish. Anyway, I will look into a micropython solution first, maybe some minor C code changes (released as development).

@bmarkus And what are the best values for getting that? (on EU zone)

@robert-hh Unfortunately not although I have converted the code to Arduino C++ and used it on an Adafruit Feather with no problem.

Hi @dmayorquin and @robert-hh, I have updated the docs, thanks for pointing it out!

@robert-hh A further look revealed, that both the LOPY4 and FIPY image are below 1536k. Only if I add one of the IN865 or EU433 regions AND my favorite frozen scripts, the FIPY build exceed 1536k. Still some slimming is advised, or more room in the partition table.

@nobo23 Accirdoig to the datasheet, you can operate that device from the 3.3V output of the WiPy. That matches the signal levels of the I2C interface. Since the module has built-in pull-up resistors (if you install the jumpers), you do not have to add additional ones.

@spookyrufus It depends whthter you have a 736x or 738x model. When you operate the device from 3.3V, you shoul dbe able to connect the Serial out from the sensor directly to the Uart RX. If it is a 736x model, you'll need a Inverter, like you can do with a 2N7000: gate -> Sensor, Source -> GND, Drain -> RX, 10k Pullup-Resistor between RX and Vcc. You may also use an inverter chip, like 74hc04 ....

@cbourne Hello, my application currently running on a LoPy4 is to collect Temperature,hygrometer,battery level value from several bluetooth BLE sensor (xiaomi) and to send all value via Sigfox, so basically, if your sensor is BLE i can confirm it's work (Sigfox or LoraWan using same radio component in different way). BUT please note that according to pycom documentation "Currently, only basic BLE functionality is available", if your sensor is not low energy this will not work in your case. If you need to connect to your sensor to do some GATT request/service my answer is no more affirmative as i dont do that.

Incase anyone else has this problem I managed to solve it. The problem was with my code. boot.py was set to launch main.py but there was a problem with main.py causing the connection to time out. The solution (which I found by accident) was to ctrl+c in the terminal window to kill main.py. It connected fine after that!