These are chat archives for esp8266/Arduino

21st
Aug 2015
bbx10
@bbx10
Aug 21 2015 00:17
@forkineye If driving WS2812 with lots of network traffic, consider building with 1.6.4-673-g8cd3697. This version does not have the WDT reset crash issue.
Michael Miller
@Makuna
Aug 21 2015 06:13
@igrr while timing between pixels seems a little more flexible, its still needs be under 800ns, that's not much time to even store and restore state let alone do anything.
Michael Miller
@Makuna
Aug 21 2015 06:22
This message was deleted
Stoian Ivanov
@sdrsdr
Aug 21 2015 10:07
OMG! spiffs excepts on SPIFFS.open
Ivan Grokhotkov
@igrr
Aug 21 2015 10:22
Works fine here (nodemcu 1.0 board, 4Mbyte flash)
Mounting FS...
Config saved
Loaded serverName: api.example.com
Loaded accessToken: 128du9as8du12eoue8da98h123ueh9h98
Config loaded
Stoian Ivanov
@sdrsdr
Aug 21 2015 10:39
Also working on the "normal" esp board here .. probably something with our "extended" development environment for the "other" board .. ok our HW/ESP guru will have to look at it
Shelby Merrick
@forkineye
Aug 21 2015 12:27
@bbx10 I've been using 1.6.5-990-gc8a63ce pushing E1.31 at 25ms rates (40Hz) driving 170 pixels. This is all just receiving UDP though. I've run tests streaming for 24 hours without any resets. My E1.31 library is here - https://github.com/forkineye/E131. I use it in my ESPixelStick, which is here - https://github.com/forkineye/ESPixelStick
Shelby Merrick
@forkineye
Aug 21 2015 12:32
This is all unicast as well. I do have reset issues however when listening via multicast. I may try 1.6.4-673-g8cd3697 and see if that remedies the issue.
These are just driving 40 pixels each - https://www.youtube.com/watch?v=XTzhO5iF_Vk
left one is a bread-boarded NodeMCU. other 3 are my ESPixelStick boards
Shelby Merrick
@forkineye
Aug 21 2015 14:32
@bbx10 it just clicked why I'm not seeing the issue. It's due to the synchronous nature of my implementation. I'm only generating a pixel stream when a new E1.31 packet arrives. With packets coming in at 25ms intervals, that leaves plenty of time for the ESP to disable interrupts and send the pixel stream in between packets.
prussiap
@prussiap
Aug 21 2015 15:26
thanks guys for all the hard work. lots of improvements lately :)
I’ve been able to teach folks about the ESPs much faster thanks to this project.
I had one quick question from my class. How do you know a library like this one would work for ESP? https://github.com/miguelbalboa/rfid or https://github.com/pkourany/MFRC522_RFID_Library
thre is probably timing stuff in here so not sure how that works
Michael Miller
@Makuna
Aug 21 2015 15:35
@forkineye if you add animations, like blend between the last value to the next, this is when you might run into issues. My library differs from the standard Ada fruit in that I added animation support. In some of the tests the values are being sent in extreme rates for testing to make it fault fast, while a more reasonable speed would only show the issue intermittently but it would still happen.
Shelby Merrick
@forkineye
Aug 21 2015 16:28
@Makuna Ah, yes. I could see that causing some issues. My project is just pumping the DMX channel data, and only one Universe (up to 170 pixels) at that. I tried driving up to 4, but was getting sporadic watchdog resets. I was assuming it was due to having interrupts disabled too long, but now I'm curious if its related to the issue with using the newer SDK. Will do some more testing this weekend, thanks!
bbx10
@bbx10
Aug 21 2015 19:17

@forkineye Good point about the synchronous nature of network LED programs. However, broadcast packets such as ARP can arrive at any time including during LED updates.

I ran into a problem doing MIDI over multicast UDP. If any WiFi device such a phone goes into WiFi power save, all WiFi devices connected to that router experienced multicast packet buffering delays and/or packet loss. I used a dedicated WiFi router for the MIDI multicast project to avoid this problem. For more details, http://goo.gl/TLDjf5. In the case of network LED programs, erratic multicast packet intervals will result in packets arriving during LED updates which might explain the WDT crashes.

Shelby Merrick
@forkineye
Aug 21 2015 19:31
@bbx10 I didn't even think about arp broadcasts. Good point. I have the ESP's all on their own access point with OpenWRT due to the multicast problems you experienced. I'm going to try some different methods creating the 2811 stream this weekend, thanks for tips!