Sophi: @1rabbit as much as we love chaos, in order to avoid it here in the chat, we uut all the questions in the comments.

Arsenijs: That's no wonder, goats are for 6GHz and up, you're supposed to sacrifice fluffy rabbits for 1-6GHz as a rule of thumb

Sprite_tm: Ah, the goggle questions. Again, dunno, deeper RF magic, not my forte, sorry :)

Billybob: :<

Michaelm: Checking in with ham radio groups would be the ideal.   Antennas can make a difference. There are onmi-directional and directional.   You would need something more directional.
Michael Anfang has joined this room.10:44 AM

Billybob: Well, the goggles have omni and patch antenna. Though the omni is circular polarized. Maybe that makes all the difference.

Billybob: Guess it's a "tryandsee"

Sprite_tm: True. The ESP32 (and the 8266) actually have pretty good RF specs, on par or better than the chips of other WiFi-companies, so at least with a good antenna you can get a fair bit.

1rabbit: i get about 200meters outdoors
hazbounn has joined this room.10:44 AM

1rabbit: with the pcb antenna

Thomas Shaddack: usually the "omnidirectional" antennas with gain work by flattening the characterstics so it has higher gain along the plane perpendicular to the antenna axis, so it radiates more there and less up and down. handy when we have an apartment that is usually mostly horizontal.

Kevin: I forgot this chat started this early. I just got here.  Hm... Sprite_tm mentions porting Doom to the ESP32? I knew the device was a capable little beast. Didn't know it was that capable.  :)

michaelm: Look up yagi antennas.  I saw a version of the ESP32 that allows an external antenna connection.

Sprite_tm: Kevin: https://github.com/espressif/esp32-doom Runs at a nice 30FPs or so.

Sophi: Q from @konsgn : any 5ghz chipsets in the works?

Sprite_tm: Yes, we do. No idea how far along it is (I think our next chip is still 2.4GHz only) but I've heard giddy sounds from some of our RF guys with interesting terms like 'really low phase noise' and 'antenna coexistence' and other things, so I can only assume we should have something good upcoming :P

Sophi: Next Q from @Simon Merrett: I'm designing a wearable temperature sensor that I'd like to keep low size, weight, power. I know ESP32 has BLE but I understand that up to this point the BLE still takes ~100mA. Are there plans to optimize BLE power to act closer to the ~10mA of e.g the Nordic chips with BLE? If so, is this something likely to be available to Arduino IDE or just in the Espressif SDK? Thanks!

konsgn: cool, good to hear

Sprite_tm: Issue is mostly that getting the thing to be anywhere near efficient is a PITA, as 5GHz amplifiers are way less efficient than 2.4GHz ones, or so I hear.

Sprite_tm: Eh, I can stay a bit longer if that's okay.

Sophi: we can do a follow up chat on this if @Sprite_tm is willing
oh that would be super @Sprite_tm !!

Sprite_tm: Meh, everyone is here anyway :P

Sophi: Next from @HCARLOTT : Anyword on the esp-idf 3.1 release date?

Simon Merrett: Sorry, no reply to mine?

Sprite_tm: Lower-power BLE: Yes, we're most certainly doing things in that direction. (That is also one of the reasons the SDK isn't visibly expanding: 'lower-power modes' is only a small bullet point but can take a huge effort to get done.) I can't tell you how much lower that is going to be, though.

Simon Merrett: Thanks

Sprite_tm: 3.1 should actually bring in a lot of those lower-power things.

Sprite_tm: For when it's released.. that's always a mystery. We're trying to get less things into the releases, because the time delay between them is irritating to us as well. If any, we are poised to keep releasing all features on the master branch as soon as we merge it, so if we have something, you'll see it.

Sophi: Next q is from @Matthias Boesl : is there any plan to support the esp32 port in zephyr OS? They are currently working on WiFi integration, and the OS seem very promising

Sprite_tm: We actually have a bunch of OSses that have interest in providing an ESP32 port: Zephyr, Nuttx, some Chinese RTOSses... We are absolutely not against integration of that, and we have some abstraction layers in the works that make it easier to integrate the (still binary, sorry) WiFi and BT drivers into foreign OSses. As it is, we will not be doing any coding for these OSses ourselves, as we lack the manpower to do that, but we're most definitely willing to help out when technical issues come up.

Michaelm: FreeRTOS and Mongoose work on ESP32.

Matthias Boesl : is there an OS agnostic WiFi blob available?

Sprite_tm: Well, FreeRTOS is what we use in esp-idf ourselves, and Mongoose isn't so much as an OS but more like a very comprehensive user space... so that's not really any 'foreign' OS.

Sprite_tm: Not yet. We're working on that.

Matthias Boesl: cool, thanks

Q from @dreamer : Will Espressif ever get rid of the binary blobs still needed to use the ESP series?
We would like to see FrostedOS on the esp32, but since this needs fully open kernel space it's currently not possible.

Sophi: lots of questions about the binary blobs!

Sprite_tm: 'Ever' is a long time... and in general this has been a pretty hard issue here, as I do think I have some influence on the company direction here. On the one hand, I'm all for open stuff, as much as possible, yes please!

Sophi: here's another about the blob from @Arsenijs : I've been discussing usage of ESP8266 as a SDIO WiFi card with people in the DIY smartphone community (specifically, in regards to the ZeroPhone project, but there are other projects I know of that currently use SDIO WiFi cards and considered replacements). There's always a question - what about the binary blob uploaded by the driver? Speaking mainly about this: https://github.com/al177/esp8089/blob/master/eagle_fw1.h, as well as the corresponding .fw2 and .fw3 files.

Are there sources? We haven't managed to find any yet. We've considered putting a bounty on reverse-engineering the blob, so that we have a WiFi card we can use internally for people that want to have an open-firmware driven WiFi card, with all the benefits it brings. However, if the sources could be made accessible, that'd be awesome. Is there anything we could do about it?

Dreamer: @Sprite_tm yeah I guess "someday maybe" is an answer. but what are the main motivations to keep these parts closed?

Sprite_tm: On the other hand, there are some risks involved. Especially with the WiFi stuff: what if your WiFi hardware can actually do much more than the binary blobs normally allow? We've already seen people make disassociation throwies with the ESP8266. What if people can disrupt more communications because you opened up the interface to hardware that allows more than is legally allowed? You can get stuff like the FCC all of a sudden requiring all WiFi firmware to be signed so no one can mess around with it.

dreamer: and could an esp be used without the blobs? (ok, not as useful without wifi/bt)

1rabbit: @dreamer good point

Thomas Shaddack: in the age of software-defined radios, do such restrictions make sense at all?

1rabbit: a knife can be used to kill or to cook healthy food

Sprite_tm: Also, there are more down-to-earth issues. For instance, we're pretty sure we have all our patent stuff covered, but what if there's something patented we've missed, hidden deep in the WiFi hardware? Seeing the bits that control it directly would make it way more visible. To make it open anyway is a choice we can make, but I'm just saying it is not entirely consequence-free.

1rabbit: same with the wifi

Milkey Mouse: *small brain* using an esp32 with binary wifi/bt blobs
*expanding brain* using an esp32 without wifi or bluetooth
*cosmic brain* interfacing an esp32 to another radio chip

Arsenijs: Avoiding exposure of patented stuff does make sense, of course

Dreamer: @Milkey Mouse brain?

1rabbit: so then from that logic we would only be able to cook with butter knifes

1rabbit: :)

Arsenijs: But there are already open-firmware WiFi cards (just USB, not WiFi)

Thomas Shaddack: @1rabbit UK actually made some noise about banning steak knives due to having a sharp tip.

1rabbit: binary blob are the butter knifes of wifi

Arsenijs: And the ESP8266 deauth stuff hasn't exactly died down - people just use the old SDK, it's still possible to do so; and yet ESP8266 is popular as ever

Sprite_tm: True, but you have to keep the practical in view as well. A SDR still is pretty expensive, and GnuRadio is all but user-friendly to the newb. When you can grab an ESP32 devboard for $5, blow some disrupt-everything firmware inthere, add 2 AAs and hide it somewhere at school/work/..., we all of a sudden are known as the company that makes those chips that kill your WiFi and endanger people because they can't call 911 on their WiFi phone.

Sprite_tm :Arsenijs: Exactly, once the ghost is out of the bottle, you can't put it back again. And that is why we are so hesitant to open-source the drivers.

Thomas Shaddack: easy remedy: do the same with more chips from other vendors.

1rabbit: the deauth thing is fun for 0.1 seconds maybe ? i tried it on myself and moved on quickly

Milkey Mouse: some people are more easily entertained by messing with people

Arsenijs: @Sprite_tm Do you actually feel any long-term consequences of that?

Thomas Shaddack: has some tactical uses in the field of electronic warfare.

Sophi: next question from @1rabbit : what kind of range should i expect from ESP-NOW in urban conditions? i have not been impressed by the range from my tests at home (a good slices of lost messages) iirc its supposed to be stronger than regular wifi, is there options to consolidate the transmission?

1rabbit says:11:10 AM
tbh if you want to do evil stuff the blobs wont stop you

Sprite_tm says:11:11 AM
Thomas: As soon as there's a chip near our price range that has the interface to the HW entirely open (and given the interface to the HW is as capable as ours), I'll start advocating to open it up within our company without a thought.

konsgn says:11:11 AM
well, not to switch topics  but to switch topics, @Sprite_tm  would you be open to having expantions to the pocket-sprite sdk in the form of alternate input methods, joysticks etc...
Hans has joined this room.11:11 AM

1rabbit says:11:11 AM
you can sharpen a butter knife prison style on the walls

Arsenijs: I'm really curious about that, since it's been possible for a while and all I've seen were some tutorials on Instructables

1rabbit: same with the blobs

Tythompson2556: Dont underestimate the shallow fear based regulation the us government wages on its people were quite lucky not to have had then crack down on some / all of it at this point

Thomas Shaddack: we need some tools for rapid reverse-engineering of blobs. generic answer to generic problem.

Thomas Shaddack: ...and we need desktop chip fabs, but that's a bridge too far for now...

Tythompson2556: +1 for decompilation @ home

Milkey Mouse: We'll cross that bridge when we burn it

Sprite_tm: Anyway, the ESP-Now question. No, ESP-Now is not supposed to be longer-range than normal WiFi. We do have a special modulation scheme that does have a longer range, but IIRC you need to enable that separately.

1rabbit: interesting

Sprite_tm: And yes, you're going to have a fair amount of packet loss, as esp-now does not do any retransmits, to my knowledge.

1rabbit: how can i enable it, is there docs on it

Sprite_tm: Erm, lemme see if I can find it...

1rabbit: nice

Thomas Shaddack: thought about code visualisation using the molecular modeling approach. instructions as atoms, links to them as bonds, algorithms for bond length to self-organize into structures, so code chains form tight strings while library calls are long and weak and their functions get segregated away.

Kevin says:11:15 AM
@Sprite_tm Thanks for the link to the info about Doom for the ESP32. Amazing.

Last question: Sort of a follow-up question to the Linux one: assuming I'm using the QFN ESP32 directly, what's the maximum SRAM or Flash I could theoretically connect to it? I've heard conflicting figures from ESP-PSRAM datasheet, esp-idf docs, hardware datasheet, etc

1rabbit says:11:15 AM
is that modulation lowering the noise floor, like lora would do?

Sprite_tm: @1rabbit: Sorry, can't find it. Suggest you read through the WiFi docs, the mode is called 'long range' mode. You enable it on the WiFi interface itself, iirc it's not ESPNow specific.

1rabbit: oh

Sprite_tm: And dunno, it uses some different modulation, but I can't even remember which :P

Tythompson2556: Hey code vis guy there's an article on mddium .com about software and bugs and the Toyota code spaghetti you might be interested in. Some or all of that should find it

Thomas Shaddack:...random weird thought... exotic modulations for very slow bitrates for low powers over large distances, like QRPp...

Ajlitt: @Thomas Shaddack sounds like LoRa

Thomas Shaddack: more like lora on steroids doped with low probability of interception.

1rabbit: ok, ill look it up, if you can find it please pm on git (1rabbit)

Sophi: Last question: Sort of a follow-up question to the Linux one: assuming I'm using the QFN ESP32 directly, what's the maximum SRAM or Flash I could theoretically connect to it? I've heard conflicting figures from ESP-PSRAM datasheet, esp-idf docs, hardware datasheet, etc

Michaelm: @Thomas Shaddack  There are modes like that used in ham radio.  FT8, JT65,, & JT9 to name a few.

Sophi: ok we also have one more after that: sprite_tm was the guy who made the SHA2017 badge, used a special ESP from espressif for it, i am wondering what he would use for the next badge project ;)

Sprite_tm: Lessee, memory to the ESP32. In theory, we support 16MiB of flash and 8MiB of SPI RAM. However, we don't have address ranges to keep that all mapped at the same time: the psram can have maximally 4MiB mapped at the same time, the flash can has 4MiB mapped as data memory and (iirc) 4MiB as instruction memory... I think there are 2 other 4MiB regions for the flash, but they are mappings for instruction memory and I'm not 100% sure if they're usable out of the box.

Sprite_tm: No, I did not make the badge. Not even close. We had a very good team of people in the Netherlands, I think I lent a hand here and there, but they did the brunt of the work.

1rabbit: @Sprite_tm is that long range mode only for the esp32 or the 8266 as well

Sprite_tm: @1rabbit ESP32-only.

1rabbit: good to know

Sprite_tm: As wrt the next badge: dunno :) I think the design of a badge wrt functionality should go first, then the component choice. (Which obviously isn't always possible because some parts you can get sponsored, others you can't.) However, I probably would go for something Espressif again, as I know we're pretty okay with sponsoring cool badges ;)


@1rabbit maybe this one https://www.esp32.com/viewtopic.php?t=1001

Dave Blundell: What do you think the chance is of getting some better CANbus transceiver in the next silicon?  The ESP32 is almost perfect for a bunch of car appplications.

1rabbit: @baoshi neat!

Kevin: @Thomas Shaddack I was thinking about FT8 as I've been hearing of an interesting experiment currently ongoing involving a platform floating out on the sea. I haven't read much about the actual protocol as I don't have a computer near my radio equipment to try any digital modes.

Sprite_tm: @1rabbit Sounds like it yes.

Sprite_tm: @Dave Blundell Anything specific you'd want?

Ajlitt: Talking about component choice, it's awesome that Espressif parts are available from major US distys like Digikey.  When will the ESP32-PICO make it to those channels? The only source I can find today with a quick search is Electrodragon