FiPy

• A

  LTE-M module in FiPy
  • Akshay Khushu  

  2
  0
  Votes
  2
  Posts
  24
  Views

  J

  @Akshay-Khushu it’s a Sequans Monarch modem. I believe it’s an SQN3330, others may be able to confirm that.
• H

  FiPy as LoRa gateway + LTE transmitter
  fipy lora lte gateway lora gateway • • Hazel Mitchell  

  3
  0
  Votes
  3
  Posts
  39
  Views

  H

  @jcaron Thanks for the info!
• P

  LTE-M1 in Canada
  fipy gpy lorawan canada • • peekay123  

  4
  0
  Votes
  4
  Posts
  745
  Views

  S

  @gldoug I've likewise been disappointed at the lack of information on connecting to Canadian cell networks. I'm a project manager looking at purchasing a FiPy for evaluation purposes. This would be our first cellular IOT project. I'm in Calgary, Alberta and looking to deploy for industrial use in British Columbia. By "sort out the requirements", which requirements are you speaking of? I presume you are talking about communicating with the carrier, is this correct? And how did you contact them? Did you need to purchase a SIM card? If so, from who? Cheers
• A

  Retrieve date and time via LTE-M
  • almeos  

  3
  0
  Votes
  3
  Posts
  33
  Views

  A

  Great! It works perfectly! Thank you Livius
• W

  Fipy with Arduino C
  • Wael Elsisi  

  2
  0
  Votes
  2
  Posts
  23
  Views

  

  @Wael-Elsisi yes and no. If you use only C then you have fipy like simple esp32 as there are no C libraries to work with specific pycom hardware like Lora and others. You have also some other way. You can build custom firmware and you can write many things directly in C. But it is harder then using it now from micropython.
• H

  Lorawan datarate
  • Hella Koe  

  4
  0
  Votes
  4
  Posts
  51
  Views

  H

  @Thierry @jcaron Thank you so much for taking your time! This helps me a lot!
• B

  FiPy board description for platformio
  • Bono Berello  

  2
  0
  Votes
  2
  Posts
  25
  Views

  G

  You should be able to use a Lopy4 or Gpy instead, or add your own board description for the Fipy. The modules are pin-compatible as you can check in the datasheets, except for the additional radios taking up some GPIO pins. Comparing the Lopy4 to the Fipy, you'll have an additional LTE radio, meaning you cannot use P17-P19. Other than that, I believe you shouldn't run into compatibility issues.
• N

  FiPy +PyTrack 2.0 deepsleep power consumption
  • Naroa Echarte  

  6
  0
  Votes
  6
  Posts
  73
  Views

  J

  @Naroa-Echarte Since you're using a FiPy, it may be due to the LTE modem staying on (though I believe in this case you would get a much higher power draw). You may want to try: disabling LTE on boot: pycom.lte_modem_en_on_boot(False) properly resetting the LTE modem before deep sleep: lte.deinit(reset=True) See https://forum.pycom.io/topic/6839/fipy-deepsleep-methods/20?page=1 for more information.
• T

  sqnsupgrade.info() result a coredump
  fipy lte coredump • • tttadam  

  3
  0
  Votes
  3
  Posts
  63
  Views

  T

  I tried the legacy firmware without the pybytes stuff. It is works all right with that fw.
• H

  This topic is deleted!
  • Hella Koe  

  1
  0
  Votes
  1
  Posts
  1
  Views

  No one has replied

• K

  This topic is deleted!
  • kannam prasad  

  1
  0
  Votes
  1
  Posts
  2
  Views

  No one has replied

• E

  FiPy WiFi analyzer
  fipy • • Ettore Bartoli  

  1
  0
  Votes
  1
  Posts
  22
  Views

  No one has replied

• L

  Delay in sending AT command
  • Lars van Velzen  

  8
  0
  Votes
  8
  Posts
  56
  Views

  L

  @Gijs Thanks this solved the problem!
• F

  Noob question: how to send data through bluetooth
  fipy bluetooth data transmit phone • • Francesco Pasculli  

  3
  0
  Votes
  3
  Posts
  77
  Views

  F

  @Gijs actually I solved my problem before seeing this , anyway it is very interesting. In particular, my problem was solved by removing if not bt.isscanning(): bt.start_scan(-1) # start scanning with no timeout print('Trying to establish connection with Nord') connection = bt.connect('ac5fea133f19') I found out these commands were not needed and they broke my code.
• K

  Wifi problem with release='1.20.2.rc9'
  • kjm  

  2
  0
  Votes
  2
  Posts
  34
  Views

  G

  Thanks, I believe this is a bug that has gone unnoticed for a very long time. The timeouterror is defined in the C-interface only, but not ported over to a micropython object, meaning throwing the error works, as that happens in C, but reading it as a micropython object does not work. I now added it in micropython I will submit the fix internally and it should be fixed by the next version! Though, note that 1.20.2.rc9 is an older release, and, even though 1.20.2.r4 also has this bug, the next release will include the fix and we will no longer update the release candidates from the past.
• T

  FiPy FTP upload in C# returns (451) Local error in processing.
  ftp • • Tasha Weidler  

  15
  0
  Votes
  15
  Posts
  42
  Views

  T

  In case someone else comes across this post looking for help: I solved the issue by using a different third party FTP library that was suggested to me on the Stack Overflow post I made: https://stackoverflow.com/questions/67011710/ftpwebrequest-to-microcontroller-always-results-in-451-local-error-in-processi/67079870#67079870 Not exactly sure what the underlying issue was, it might've been that the fipy explicitly wants you to change your working directory to the flash directory before uploading or it might've been something else in the library that handled it better. Either way, my FTP log now more closely matches the one from FileZilla and no more errors! My New Code: FtpClient client = new FtpClient("ftp://192.168.4.1"); client.Credentials = new NetworkCredential(UserId, Password); client.DataConnectionType = FtpDataConnectionType.PASV; client.Connect(); client.SetWorkingDirectory("/flash"); client.UploadFile(appFilepath, "rwis_config.py", FtpRemoteExists.NoCheck); client.Disconnect(); New FTP Log Output: # Connect() Status: Connecting to ***:21 Response: 220 Micropython FTP Server Command: USER *** Response: 331 Command: PASS *** Response: 230 Command: FEAT Response: 211 no-features Status: Text encoding: System.Text.ASCIIEncoding Command: SYST Response: 215 UNIX Type: L8 # SetWorkingDirectory("/flash") Command: CWD /flash Response: 250 # UploadFile("rwis\rwis_config.py", "rwis_config.py", NoCheck, False, None) # OpenWrite("rwis_config.py", Binary) Command: TYPE I Response: 200 # OpenPassiveDataStream(PASV, "STOR rwis_config.py", 0) Command: PASV Response: 227 (192,168,4,1,7,232) Status: Connecting to ***:2024 Command: STOR rwis_config.py Response: 150 Status: Disposing FtpSocketStream... Response: 226 Status: Testing connectivity using Socket.Poll()... Command: QUIT Response: 221 Status: Disposing FtpSocketStream...
• S

  This topic is deleted!
  • sobhan sepehri  

  2
  0
  Votes
  2
  Posts
  17
  Views
• S

  This topic is deleted!
  • sobhan sepehri  

  1
  0
  Votes
  1
  Posts
  2
  Views

  No one has replied

• N

  PyTrack's Accelerometer sampling rate
  • Nikhil parashar  

  4
  0
  Votes
  4
  Posts
  51
  Views

  J

  @Nikhil-parashar The implementation in LIS2HH12 library is pretty basic and reads each of the 3 axis in turn, one by one, which probably isn't very efficient. Not sure if that's the limiting factor here, but if you want to receive data at high data rates, you probably need to: Activate one of the FIFO or stream modes (see section 5.3 of the datasheet) Read larger amounts in one go. You can read all 6 bytes in a single I2C command, and you can even read multiple sets as the address counter will loop back to the first output register (see section 5.3.8 of the datasheet). This has been discussed here and here, though apparently not very successfully, with I2C bus issues. Also micropython is probably not the most suitable environment to read realtime data in this fashion. The FIFO is quite small and is easy to overrun if you use the higher update rates. What are you trying to achieve with high sample rates? As much as possible, you should let the accelerometer do things internally (e.g. detect if acceleration goes over a threshold, for wake-on-motion, tap detection, pedometers, etc.), and only get interrupts when the conditions are met. If you are trying to do dead reckoning / inertial navigation then I'm afraid this is probably not the right combo to get any decent results unless you have a relatively stable environment (i.e. device fixed in a car on a highway as opposed to someone walking and holding the device in their hand). A real integrated IMU (which does the integration on-chip) will probably get you better results (and you're lacking a magnetometer and gyroscope anyway), within the limits of inertial navigation of course (after a few minutes you'll be meters away even in the best conditions).
• A

  FiPy on Telia Norway LTE-M1
  fipy lte • • albert  

  8
  1
  Votes
  8
  Posts
  1839
  Views

  F

  @GeirFrimann hello, I`m just starting out, can you share your settings for telia?