Feature Request 🚀

Hi
I am collecting data from a bunch of sensors, placing it in a dict, then dumping the dict as a json string to a text file that's saved to the SD card following the docs example. I then have to load the data into pandas on my laptop, it's all a but tedious. Much nicer would be if I could just dump straight into a dataframe that was then pickled on the SD card, and could then be loaded straight into pandas

Hi,
I tried to find how to insert nano-simcard into FiPy in the docs, but it wasn't probably still included.

People were already talking about it here, maybe we could include it in docs https://forum.pycom.io/topic/2486/nano-sim-card-orentation/2

Documentation Page
PDF Pinout

In the Pin-Out diagram of the development modules and the OEM modules, the label "SD_DATA0" is missing at P8.

Correct function definition header for socket.send.
Replace:

socket.send
Send data to the socket. The socket must be connected to a remote socket.

with

####<function>socket.send(bytes)</function>

Send data to the socket. The socket must be connected to a remote socket.

Updated file is attached.
usocket.md.zip

I am using a LoPy4 with an Expansion Board 3.0.

• Section 1.2.3 (Atom), under "Connecting via Serial USB," you mention that you need to "remove the wire between GND and G23." This step does not need to be performed on an exp board 3.0.

Hi,

The get_wake_reason is not documented while still being used in the the examples or in the documention:

There is also multiple confusion in the forum about this method.

• What is the status of this method ?
• Should it be documented ?
• Why this method is defined in pycoproc_1.py but not in pycoproc_2.py ? does that mean this method can't be used with pysense 2 and pytrack 2 ?

Can anyone provide some clarity about this ? Thank you

Hello Pycom folks, some of the newer methods in the pycom module are not documented. These include:
get_pulses()
ota_start(), ota_write() and ota_finish()
A few words, at least about get_pulses() would be helpful for many.

The Pinout for the expansion board 3 labels the pins as GPIOxx instead of Gxx. The expansion board 2 labels are fine.

I'm talking about the one at https://docs.pycom.io/chapter/datasheets/downloads/wipy2-pinout.pdf
a) P12 is NOT the antenna selection pin. That pin is internal and is GPIO16, like written at another place in the diagram.
b) Pulling P12 high at boot time just skips boot.py and main.py. There is not previous or factory image, which is selected. The respective section in the boot documentation is also wrong. This statement is also wrong in the other pinout diagrams.

Add a manual for the expansion board.
https://github.com/pycom/pycom-documentation/blob/master/chapter/datasheets/boards/expansion.md

A good start would be the previous expansion boards manual: https://github.com/wipy/wipy/blob/master/docs/User_manual_exp_board.pdf

Add the expansion board schematics

https://github.com/pycom/pycom-documentation/blob/master/chapter/datasheets/boards/expansion.md

The schematics are needed by developers to correctly use the hardware.

in ADC example at https://docs.pycom.io/chapter/tutorials/all/adc.html, there is a link to self
"For more information please see ADC." and ADC contain link to same article

The "S1" button is not on G4/GPIO4, as stated.
It is on G7/GPIO17, where it is on expansion board 2.0, too.

While trouble shooting an issue with my LoPy it looks I uncovered a discrepancy between docs and implementation for coding_rate.

modlora.c shows:

typedef enum {
    E_LORA_CODING_4_5 = 1,
    E_LORA_CODING_4_6 = 2,
    E_LORA_CODING_4_7 = 3,
    E_LORA_CODING_4_8 = 4
} lora_coding_rate_t;

While docs indicate:

lora.coding_rate([coding_rate]) Get or set the coding rate in raw LoRa mode (LoRa.LORA). The allowed values are: LoRa.CODING_4_5 (0), LoRa.CODING_4_6 (1), LoRa.CODING_4_7 (2) and LoRa.CODING_4_8 (3).

I think this is just a documentation issue as setting the coding rate to 0 on the sx1272 would put it in FSK mode.

I am reporting this issue here again and removing it from our Jira.

In FiPy pdf datasheet on this page https://docs.pycom.io/datasheets/development/fipy
on a third page, a device sticker is upside down compared with a real device.

it can lead to confusion which antenna is sigfox/LoRa and which is wifi/Bluetooth

I would expect a preamble instead of a coding constant.

Kind regards,
Josh.

XPOST: pycom/pycom-micropython-sigfox#186

The schematics are necessary for some developers to correctly use the WiPy.

The method which tells the free space of a file system is implemented as uos.getfree(path).
The documentation calls it uos.space_free(path).

Documentation says 115kOhm/56kOhm on overview page, but 1MOhm/1MOhm on details page (pdf).
Don't know what's correct here, i assume 115/56 is from expansion board 2.0, so 1M/1M could be new value for expansion board 3.0?

There was an error with your serial port module, Pymakr will likely not work properly. Please try to install again or report an issue on our GitHub (see developer console for details)

Hi!

I just spent a while getting a headache related to this. In the definition of the connect() function for WLAN, there is not a specification for the format for the BSSID. This is specified higher up in wlan.scan(), but not under connect(). Something to consider for clarity :)

The link for the DFU utils tool, at pycom-documentation/content/updatefirmware/expansionboard.md (or, if you prefer, the website link) is insecure.

I know pycom are not the maintainers of this software but could we at least get a shasum of it somewhere?

What are the steps to reproduce this issue?

1. go to this page https://docs.pycom.io/tutorials/all/mqtt
2. copy mqtt example by selecting the code from the web page (not pressing the copy button)
3. upload this code to a device and restart the device

What happens?

The device fails to execute the code at line 5, then on line 9 and so on.

There are unprintable characters on line 5 and 9 rendered with HTML with Gitbook.
These unprintable characters aren't visible in Atom but might be visible in other IDEs or editors.

Furthermore, the copy button is too small and has low contrast.

I think the pinout for the 'J4' external IO Header in the PySense2X_specsheet.pdf (version 1.0) is not correct. It is basically the numbering of the pins of the 10-pin header that is wrong. And the pinout lacks information about which pins of the pycom module the 10-pin header is connected to. I made corrections on the following exert from the specsheet:

I'm trying to reflash the Expansion board 3.1 firmware and hence going through the docs at website/github.

There it states (highlights mine):

Windows

Download and install DFU-util v0.9

For Windows, we will need to install separate drivers for the board to recognized as a Pycom board in DFU mode.

1. Disconnect the USB cable to your expansion board
2. Hold down the DFU mode button on the shield

• Zadig – Installer tool for the Pytrack/Pysense board DFU Firmware

To install the drivers, the board must be in DFU-mode:

1. Disconnect the USB cable
2. Remove the development module from the expansionboard.
3. Hold down the button on the shield
4. Connect the USB cable
5. Keep the button pressed for at least one second

Which button is mean by "the DFU button" or "the button"? I have two on my board.
This should be more clear.

Thank you in advance.

(Hi! 👋 Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

What are the steps to reproduce this issue?

1. Executing the SD example code.

What happens?

the example code in SD uses a function for read files "f.readall()" that function doesn't exist and the micropython gets an error.

What were you expecting to happen?

Any logs, error output, etc?

(If it’s long, please paste to https://gist.github.com and insert the link here)

Any other comments?

What versions of software are you using?

• Board type and hardware version: FiPy
• os.uname() output: (sysname='FiPy', nodename='FiPy', release='1.20.2.r1', version='v1.11-a5aa0b8 on 2020-09-09', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.6.0')
• Atom/VSCode version:
• Pymakr version:1.1.7
• Operating system: Linux

As mentioned by robert-hh Mar 3, 2019, 4:53 AM in https://forum.pycom.io/topic/4472/argument-order-of-time-ticks_diff

• "since Nov 8, 2018. The argument order has been swapped. it is now time.ticks_diff(new, old). That is good and bad.
  Good, in that it matches what the uasyncio library expects and
  Good in that it is now compatible with the micropython.org branch.
  Bad, since existing code for the Pycom devices which make use of this call now breaks."

For example:

start = time.ticks_us()
time.ticks_diff(start, time.ticks_us())
-7646164

Please revise https://docs.pycom.io/firmwareapi/micropython/utime/ accordingly

(sysname='FiPy', nodename='FiPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.6.1')

I'm trying to establish an HTTPS connection between a FiPy (client) and a public website (server). The blynk example on this page does not seem to work anymore.

A bit of context:

• I started out with the Blynk example on this page, which I cannot get to work. The following error occurs on the line where the socket is wrapped: OSError: -8576 (no idea how to trace back these obscure error codes to the real problem). Here's my code and project structure in Atom:
• I uploaded the Blynk server certificate both via Atom and via FileZilla (in the /flash/cert folder): same result. When the certificate is not present, the following error is thrown: OSError: CA file not found. This leads me to believe that the certificate is indeed found in the former case.
• Following the advice in this forum post, I first synchronized the RTC (Is this even necessary? The official Pycom docs don't seem to mention it.). Unfortunately, without any luck (same error). Here's the code for that:

Can anyone point me in the direction of a working example that actually works?

Hello,

I would like to find more infos about the lora.stat part.
Cannot find the 'network' files from: 'from network import lora' in the pycom repositories ?
Nor the pycom firmwareapi codes such as in:
https://docs.pycom.io/firmwareapi/pycom/network/lora/

Thanks

Just look at. https://docs-mk2.readthedocs.io/en/latest/gettingstarted/connection/gpy/

What happens?

See formatting info like: {% tabs %} {% tab title=“Exp Board 2.0” %} *
Many PNG images missing for example
https://docs-mk2.readthedocs.io/en/latest/gettingstarted/connection/gpy/.gitbook/assets/baregpy.png

What were you expecting to happen?

finished documentation

The OneWire library has been updated to use the correct spelling of "conversion" but the OneWire tutorial code has not. A simple find and replace of convertion to conversion should do the trick.

Attached is an updated version if it helps

Thanks!

owd.md.zip

Feature Request 🚀

Currently https://docs.pycom.io/firmwareapi/pycom/machine/rtc does not show a nice example of formatting the datetime as a string. This would be useful as the standard python approach doesn't appear to work - rtc.now() returns a tuple and strftime is not anywhere in the pycom library from what I can see.

>>> rtc.now()
(2018, 11, 9, 5, 18, 18, 201719, None)
>>> rtc.now().strftime("%m%d%H%M%S")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'tuple' object has no attribute 'strftime'

in python [ref]
local time = utc - timezone

in pycom micropython [ref]
local time = utc + timezone

there should be a big warning sign about this somewhere in the documentation.

There are a number of issues with the SQNSUpgrade procedure documentation here: https://github.com/pycom/pycom-documentation/blob/master/tutorials/lte/firmware.md

1. No explanation given for how to get sqnsupgrade code onto board, adding it as a lib in a project leads to no property run on sqnsupgrade.
   Solution: explain that sqnsupgrade folder in lib needs to be uploaded as a standalone project, not a lib

2. No explanation given for difference between "recovery mode" and "normal update mode", the document warns several times that a special "recovery mode" must be used or you risk bricking your device, yet it never explains what that actually is or how it differs from a normal mode, or what the normal mode is

3. Which SQNS firmware should be used https://software.pycom.io/downloads/sequans2.html ? No indication is given as to which version should be used, the most recent? or is there some special version that must be paired with the firmware on the board

All in all, the whole process took me multiple weeks with many hours of headscratching, and I'm not even sure it's working now because lte = LTE() hangs for >10min and my board seems to be bricked.

Why can't this whole process be handled by the Pycom Firmware Update tool so it "just works"? Sorry for ranting, it's just that I'm on the verge of returning this board because I've been trying to get it working on LTE with weeks of struggling and no luck.

>>> sqnsupgrade.run('/sd/CATM1-39529.dup', '/sd/updater.elf')
<<< Welcome to the SQN3330 firmware updater >>>
Attempting AT auto-negotiation...
Session opened: version 1, max transfer 2048 bytes
Sending 429340 bytes: [########################################] 100%
Attempting AT wakeup...
Upgrader loaded successfully, modem is in upgrade mode
Attempting AT wakeup...
Starting STP ON_THE_FLY
Session opened: version 1, max transfer 8192 bytes
Sending 6059510 bytes: [                                        ]   1%SRSP header too small: 0
Code download failed, aborting!

May be related to: pycom/pycom-libraries#81

Really extremely corner case

all pinouts wipy, lopy, pdfs have document description title as "gpyPinout"
and when we show it in the webbrowser, page title is inherited from it

To reproduce : click on hugo.io at the bottom of (https://github.com/pycom/pycom-documentation/blob/publish/README.md)

What happens: 404 is reported

We have a few W01 modules. We are trying to implement them in a new design but we are unable to update the firmware. I have grounded p2 (pin5) then momentarily grounded the reset pin but the W01 will not enter bootloader mode. By watching the REPL it appears to reset but then boots normally regardless of the grounding of p2. Am I missing something here?

The page chapter/firmwareapi/pycom/machine/README.md contains information about the machine.unique_id(), within which there is a breakout box suggesting the use of binascii.hexlify(). The correct module name should be ubinascii.hexlify()

Update file attached

README.md.zip

As title, linked from https://docs.pycom.io/gettingstarted/wipy.html