Discussion

• C

  Firmware updates are not consistent
  firmware • Feb 6, 2017, 9:13 AM • constantinos   Feb 7, 2017, 12:19 AM

  2
  0
  Votes
  2
  Posts
  1.0k
  Views

  Feb 7, 2017, 12:19 AM

  i understand... got a couple of sipy's and it has just been a nightmare. pymkr is very buggy....it doesnt always connect . i have to do a lot of firmware resets, it is just a nightmare..
• 

  SO_KEEPALIVE usocket option ?
  Jan 12, 2017, 9:26 AM • mkharibalaji   Jan 22, 2017, 4:03 PM

  8
  0
  Votes
  8
  Posts
  2.4k
  Views

  Jan 22, 2017, 4:03 PM

  @Wembly, to add my two cents as a sockets user, in the past I tried to use KEEPALIVE for this kind of applications, and fount it to be unreliable (I don't wanna say useless). For example, the default behavior for all Linux distros I've seen is not to start sending KEEPALIVES until 2 hours of inactivity (that's the shortest recommended interval). Yet, some small devices like home routers will start silently closing connections way before that, so you can easily have more than an hour 45 minutes of quietness without actually realizing the connection was dropped. The specific reasons not to rely on SO_KEEPALIVE, at least how I read them, are mentioned here: https://tools.ietf.org/html/rfc1122#page-101 (section 4.2.3.6). This interval MUST be configurable and MUST default to no less than two hours. If a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection. The TCP specification does not include a keep-alive mechanism because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets. Whenever I've dealt with this situation (knowing if the other end is still there), I implement it pretty much the same way you did. I'm by no means a protocol expert, so if you have important reasons for the need of this feature, I can try push it higher on the list.
• 

  Test machine.idle() - fw 1.4.0.b1
  Jan 22, 2017, 1:04 PM • affoltep   Jan 22, 2017, 1:04 PM

  1
  0
  Votes
  1
  Posts
  971
  Views

  No one has replied

• N

  LoPy ADCs
  Nov 9, 2016, 1:17 AM • Nick   Jan 16, 2017, 7:27 AM

  17
  3
  Votes
  17
  Posts
  12.8k
  Views

  Jan 16, 2017, 7:27 AM

  Some LoPy specs and performance that it would be useful to know, theoretically and measured : flash memory available for MicroPython user; LoRa speed and range in real user cases; Bluetooth speed and range in real user cases.
• 

  git
  git • Dec 30, 2016, 8:22 AM • livius   Dec 30, 2016, 8:48 AM

  2
  0
  Votes
  2
  Posts
  1.1k
  Views

  Dec 30, 2016, 8:48 AM

  I see - i press commit but should press commit to new branch is possible to revert this commit from pull request and commit to my custom branch?
• 

  Pycom Github repository screwed up (?)
  Dec 21, 2016, 6:36 AM • robert-hh   Dec 21, 2016, 11:28 AM

  4
  0
  Votes
  4
  Posts
  1.3k
  Views

  Dec 21, 2016, 11:28 AM

  Thank you for the response.
• 

  LoPy/WiPy 2/ESP32 specs and performance
  Nov 2, 2016, 1:45 PM • rcolistete   Nov 27, 2016, 4:47 AM

  9
  0
  Votes
  9
  Posts
  7.6k
  Views

  Nov 27, 2016, 4:47 AM

  With firmware v0.9.5.b1 (19/11/2016), the measured specs for : WiPy 2.0 : free RAM 79152 bytes; 499 KB of free internal "/flash"; LoPy : free RAM 79152 bytes; 497 KB of free internal "/flash". With firmware v0.9.6.b1 (25/11/2016), the measured specs for : WiPy 2.0 : free RAM 79152 bytes; 498 KB of free internal "/flash".. LoPy : free RAM 79152 bytes; 497 KB of free internal "/flash".. So the free RAM wasn't changed since v0.9.3.b2. Updated the benchmarks below with v0.9.5.b1 and v0.9.6.b1 releases.
• 

  DAC (Digital to Analog Converter)
  Nov 19, 2016, 10:55 AM • rcolistete   Nov 25, 2016, 3:31 PM

  5
  0
  Votes
  5
  Posts
  2.5k
  Views

  T Nov 25, 2016, 3:31 PM

  Looking forward to DAC support!
• U

  Q: flashing custom firmware on the WiPy 2.0
  Nov 2, 2016, 9:38 AM • ubiq_01   Nov 3, 2016, 6:53 PM

  3
  0
  Votes
  3
  Posts
  2.1k
  Views

  U Nov 3, 2016, 6:53 PM

  Problem solved. It works well both on Linux and OSX - just the flashing failed when doing from Linux running in VirtualBox on OSX. https://twitter.com/_rac01/status/794250206489575424 best regards and many thanks for the support Ralf
• R

  framebuff module?
  Oct 27, 2016, 5:26 AM • remcohn   Oct 27, 2016, 5:26 AM

  1
  1
  Votes
  1
  Posts
  865
  Views

  No one has replied

• D

  WiPy 2.0 deepsleep not working?!
  Oct 25, 2016, 7:25 AM • dan1824   Oct 25, 2016, 2:18 PM

  3
  0
  Votes
  3
  Posts
  1.4k
  Views

  H Oct 25, 2016, 2:18 PM

  Isn't there an overview of the features that are already/not yet implemented. I had the same problem yesterday and spend maybe 4 to 5 hours getting the damn thing to sleep before I gave up.
• F

  Use AES engine outside of uSSL
  Oct 20, 2016, 11:02 AM • flemlion   Oct 20, 2016, 12:38 PM

  3
  1
  Votes
  3
  Posts
  1.2k
  Views

  D Oct 20, 2016, 12:38 PM

  Hello, Yes the AES functionality is going to be available, with an API similar to this one: https://pypi.python.org/pypi/pycrypto SSL/TLS is also coming soon.
• 

  OTA Updates on LoRa class C
  Oct 14, 2016, 8:21 AM • KDHeard   Oct 14, 2016, 8:42 AM

  4
  0
  Votes
  4
  Posts
  1.9k
  Views

  D Oct 14, 2016, 8:42 AM

  Hello Kevin, Yes of course, I totally understand. I'll share the development plan very soon. Cheers, Daniel
• M

  AF_LORAWAN
  aflorawan • Oct 13, 2016, 6:36 PM • mctouch   Oct 13, 2016, 8:01 PM

  2
  0
  Votes
  2
  Posts
  1.1k
  Views

  D Oct 13, 2016, 8:01 PM

  Hi mctouch, Sorry, there was a typo in the example, LoRaWAN sockets are also created with: s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) The example in the docs should be correct now. Cheers, Daniel