I need to publish state of a switch (1/0) to an MQTT broker. I am planning to put it to deepsleep since this is a battery operated application. Is there a way to awake ESP8266 from deepsleep using external interrupts?
When the state of the switch changes, ESP awakes and transmits switch state to MQTT broker. After that it again goes to deepsleep.
I found no information about external interrupts in ESP. As I got to know, only clock is ON during deepsleep and not sure whether my goal is feasible. If not, I would be glad if you can please suggest an alternative for this (using ESP).
Lakmal
Sure, see the discussion here, basically if CH_DP goes high the chip wakes up.
You can also try my solution here. I use one transistor to enable interrupt to reset after ESP wakeup from deepsleep.
Related
I know I can send 802.11 custom packets with wifi_send_pkt_freedom, and I'am using it without any problem.
But what about receiving?. Yes, I can enable promiscuos mode, and filter by MAC address. Doing that is perfect for sniffing, but not for communication, because the ESP8266 won't ACK the packets and if I'am not sniffing and my ESP is the only receiver, it will make the transmitter to repeat many times the packet. Yes, I can send it like broadcast or multicast to avoid waiting for the ACK, but I'll missing the ACK/re-send functionality. In short I would like to put the ESP Wifi interface in monitor mode (which is not promiscuos mode)
And yes, I can use ESPNOW, but for my application it wont suit very well my needs.
Thanks!
Román
My understanding is that current WiFi driver uses rate control algorithm to choose a data rate within a small set of predetermined values to send packets over the WiFi medium. Different algorithms exist for this purpose. But how does this process work when WiFi driver decides that the connection is lost and shutdown the connection all together? Which part of the code should I read in open source WiFi driver such as MadWiFi and the likes?
The WiFi driver for your hardware which runs in Linux communicates with the WiFi chip which also runs a pretty complex firmware. The interface between the driver and the firmware is hardware specific. In some hardware the detection of connection loss events is done completely by the firmware and the driver only gets a "disconnected" event while in others the driver is also involved.
Regardless of who does what disconnection usually occurs due to either
Receiving a DEAUTH frame from the AP
Detecting too many missing beacons. Beacons are WiFi frames sent periodically by the AO (for most APs every ~100ms) . If you get too far from the AP or the AP was just powered off you stop seeing the beacons in the air and usually you'll signal disconnection or try to roam to a different AP.
Too many failures on Tx of packets (i.e. not receiving ACK frames for too much traffic)
This usually indicates that you've gone too far from the AP. It could be that you can "hear" the AP but it can't hear you already. In this case it also makes sense to signal a disconnection.
For example you can look in TI wifi driver in the Linux kernel drivers/net/wireless/ti/wlcore/events.c and the function wlcore_event_beacon_loss()
In Cfg80211 architecture, assume we are station mode.
driver call kernel API cfg80211_send_disassoc() if we received a deassoc/deauth frame.this function will notify corresponding application (ex wpa_supplicant) a disconnect event.
on another hand, when we decide to disconnect with AP, applicantion (ex wpa_supplicant) can call linux kernel API cfg80211_disconnected(), it will trigger corresponding driver ioctl function to finish disconnection task.
I am trying to understand BLE and GATT in more depth. My interest is in the max achievable number of reads you would able to make per second over the GATT profile.
I am aware of some of the post made on this topic before, for instance:
Bluetooth Low Energy - updating a characteristic value repeatedly
However, I am trying to explain these results looking at the BLE specification.
What is the relationship between connection events and GATT? Does each ATT read/write require a new connection event? If not, is it possible to say anything about how many ATT read/writes can be made per connection event?
Say I want to poll a BLE connected light sensor for a single byte value, what would be the max Hz I could achieve? Would it always be best to set the mininum connection interval as low a possible?
Would I be able to achieve better results using "GATT server notifications? In the BLE spec (Core_v4.0) it says that "The master initiates the beginning of each connection event". Then how are GATT server notifications implemented? I would think that would require the server to initiate a connection event.
Finally, if anybody knows about any specific iOS imposed limitations on the throughput I would be able to achieve when polling a sensor intensively, I would love to hear about it.
I can answer a portion of of those questions...
What is the relationship between connection events and GATT?
They're different levels of the protocol. You handle connections and connection events via HCI. GATT is something you use after you've connected.
Does each ATT read/write require a new connection event?
No. Once you're connected you can do multiple read/write or other GATT commands.
If not, is it possible to say anything about how many ATT read/writes can be made per connection event?
I think the best method is to actually benchmark the speed yourself. However, the whole point of BLE is a reduction in power usage at the expense of speed. If you're concerned about speed that you probably shouldn't be doing it with BLE. The whole point of notifications/indications is so you don't have to poll an attribute but only get a message when a certain event has occurred.
Say I want to poll a BLE connected light sensor for a single byte value, what would be the max Hz I could achieve? Would it always be best to set the mininum connection interval as low a possible?
See above 2 answers.
Then how are GATT server notifications implemented?
Once you've implemented a GATT connection there's 2 way communication going on between the master and slave-device. Either device can send events to the other. In order to use notifications, you set a bit on a particular attribute to say you want notifications on that information. Then, depending on how that notification works, you'll get events sent back to you whenever there's something to report. I have a feeling that a lightbulb wouldn't have any sort of notification unless there's some interface on it besides the BLE connection. I typical application would be something like a thermometer where it would send a notification every time the temperature changed by 1 degree.
Conclusion:
If you're polling attributes you're doing it wrong. But it's possible that you have to do it wrong because the device didn't properly implement notifications in the way you need and you can't modify the device. However, polling will ramp up the battery usage significantly and you'll have loss the benefit of using BLE.
My app communicates with an external device via EA Framework. I would like to do a "soft disconnect", i.e. a software disconnect without actually physically disconnecting the device. The only way I see for a soft disconnect is to close the EASession's inputStream and outputStream. Question: Will the external device know I have closed the streams so it doesn't attempt to communicate further? Is there another way to do soft disconnect?
i think that actually is impossible to do a real soft disconnection.
i say 'think' cause you never stop learning on EA Framework (One week ago i found the showBluetoothAccessoryPickerWithNameFilter for example, maybe is useful for you for inApp-connection).
I use a EASession(s) manager to easily switch between connections. so forgot the word 'disconnection' and replace it with 'switch' :D
If you need disconnection, implements some function on btdevice-side and execute this to disconnect as soon as you receive a command from the iPhone.
For a GPS tracking app, recording location signals with WIFI turned on results in really imprecise data or data with gaps.
I've used the Reachability queries to detect if wifi is available prior to starting tracking. The problem is that if when that query is made the wifi is enabled but not connected to a network, it shows that the internet is not reachable via wifi, but that's not an indication of if the setting is disabled in the settings app. This means that if the user starts running and a connection is made mid-run, they'll get a location signal from the wifi instead of the GPS or cell network. Consequently the accuracy on those data points can be > 10 meters so I want to skip that point. The issue is that on wifi they'll have a large blank period where their signal wasn't recorded.
So how can I check if wifi is enabled but disconnected?
I've read all the other reachability discussions I could find but this seems to be the one gap with lots of responses incorrectly suggesting that reachability solves this out of the box.
...and I'm not going to require wifi - just alert them to the fact that it is enabled so at some point in their workout their location data might be lost (due to inaccuracy).
It's been quite a while since you asked, but I just came across this one.
It doesn't look like there is any way to do it if you want to obey Apple's rules. sysctl and ioctl won't work because there are no flags which will show you wether WiFi is enabled. For example the flags for "UP" and "RUNNING" will be the same if WiFi is disabled or WiFi is enabled but not connected.
Apple's own WiFi framework uses mach to directly communicate with the kernel and I doubt Apple would allows such code in the AppStore.
This IS possible, but the solution is obscure and ugly. The short answer is that if you see TWO interfaces with the name "awdl0" then WiFi is enabled, just one and it's disabled.
See Better way to detect WiFi enabled/disabled on iOS? for a more complete description and sample code.