Different WiFi modes in arduino for esp32 - esp32

I've recently started playing with esp32. I was searching for various WiFi.mode() options available for esp32 but I couldn't find it anywhere. Can anyone help point out the source for that information?
Thanks

The code for the ESP32 Arduino SDK WiFi class is located at
https://github.com/espressif/arduino-esp32/tree/master/libraries/WiFi/src
WiFi.h doesn't define a method for mode() but it does inherit from WiFiGeneric.h which does have methods for mode() and getMode(). You can find the code for those methods in WiFiGeneric.cpp.
The mode is represented using type wifi_mode_t, which is defined in WiFiType.h. The available options are WIFI_MODE_OFF, WIFI_MODE_STA, WIFI_MODE_AP, and WIFI_MODE_APSTA.

There is some resonable but partial doc on the Espressif pages: Espressif Wifi doc
This doc explains some of the different wifi modes of the esp32 that can be found in WiFiType.h.
WIFI_MODE_NULL : The null mode or the WIFI_MODE_OFF which is the OFF mode
WIFI_MODE_STA : The Station mode, which is the standard client mode
WIFI_MODE_AP : The Access Point mode where clients can connect to the ESP32
WIFI_MODE_APSTA : The hybrid mode where the ESP connect to an AP as a client and recieve connections from client as an AP.
WIFI_MODE_MAX : The MAX mode has no explaination on what it is supposed to do. But it dose not seems to be implemented anyway.

The WiFi mode types come from an enumerated list. WIFI_MODE_MAX is the last entry in the list (and I guess that's why it's MAX). An odd convention as WIFI_MODE_UNKNOWN or similar would be more intuitive.

Related

How to check channel state from MAC layer

In Omnet++ 5.5.1 with INET 4 framework, from MAC layer, I am trying to check if the physical channel is idle.
Would anyone please suggest me the code for that?
UPDATE
I'm using the following interface.
# wireless interface
**.wlan[*].typename = "WirelessInterface"
**.wlan[*].radio.typename = "ApskScalarRadio"
Thanking you.
Usually radios implement the IRadio interface, and the medium state can be queried through various methods on that interface. Check the CsmaCaMac.cc file for examples. Here is the actual implementation you are looking for:
https://github.com/inet-framework/inet/blob/master/src/inet/linklayer/csmaca/CsmaCaMac.cc#L593

WinRT/C++ issue with concurrent MIDI and BLE communication

My team has been struggling with a pretty strange issue while using the WinRT/C++ APIs for Windows to connect to both a MIDI port and receive BLE notifications through a proprietary service on the same device.
The WinRT/C++ library itself is really nice and provides easy and modern C++ interfaces to access the managed Windows runtime classes.
I've pushed a sample repo to Github where we've replicated the issue with a minimal example.
The repo's readme goes over the problem in detail, but I'll post the relevant bits here for completeness.
The sample program is performing roughly these steps:
Check for available MIDI devices using a DeviceWatcher.
Check for available Bluetooth LE devices using another instance of a DeviceWatcher.
Match discovered MIDI and BluetoothLE devices on their ContainerId property (see DeviceInfo for details). This is the method JUCE employs in the native WinRT code for their library, and works as expected.
Open the MIDI port and attach a handler to the MessageReceived event (see the code).
This causes the system to create a connection to the Bluetooth LE device. The program detects this state change, creates a BluetoothLEDevice, we perform GATT service discovery and attach a handler to the ValueChanged event for the characteristic we're interested in notifications from (see the code).
The program then counts how many MIDI messages are received on each port and how many BLE notifications are received from the corresponding device.
The behaviour we notice is that data from the most recently connected device streams just fine, while the throughput for the others is severly limited. We are at quite a standstill regarding this issue, and are not sure where the problem may lie.
We are at quite a standstill here. I'd be more willing to accept it if all the devices would exhibit this behaviour, but that's not the case. Is there any reason that creating both a MidiInPort and an BluetoothLEDevice from the same peripheral should cause this issue?
A BLE radio can only receive or send at any given time. And therefore only communicate with one device at any given time. It uses a scheduler to allocate radio time for every device when you have many devices. That way a second connection can "interrupt" a connection event from another device, decreasing the throughput for that device. See https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html

how to find the number of COM ports and their resources?

I am writing a serial driver for UART in windows just for learning purpose. More specifically in WDM.
I will write both the bus driver and function driver.
Currently i am writing the bus driver. So my question is from where i can come to know in my driver that how many serial ports i have in my system, so that i can expose that number of PDO's from my bus driver?? And resources allocated to each port. Do i have to check some kind of registry or windows will provide some kind of structure.
Please help me!! Thanks in advance
Assuming your UARTs are part of the PC, there's already a bus driver which will enumerate them. ACPI.SYS gets information from the platform BIOS, which includes the number and resource assignments for built-in components like UARTs.
If you're writing your driver for an add-in multi-port serial board, then you would need to look at the documentation for the board to determine how you find the number of UARTs. It might be as simple as looking at the PCI Product ID and having a hard-coded count for the type of board you have.
When ACPI enumerates the device, your driver's AddDevice routine will be called to load on it, and you'll receive the assigned resources when handling the PNP START message.

Multiple Kinects using Kinect for Windows SDK 1.5

I'm trying to make two Kinects getting along under the same application. I've tried to start all the connected Kinects (by calling the Start() method), but only one has the "isRunning" flag set on true. Does anyone know why is only one sensor running?
LE: I connected the two kinects on different USB controllers ... same problem. I've enabled all exceptions, and I get this, when the start method is called for the second kinect:
This API has returned an exception from an HRESULT: 0x830100AA
The stack trace:
at Microsoft.Kinect.KinectExceptionHelper.CheckHr(Int32 hr)
at Microsoft.Kinect.NuiSensor.NuiInitialize(UInt32 dwFlags)
at Microsoft.Kinect.KinectSensor.Initialize(SensorOptions options)
at Microsoft.Kinect.KinectSensor.Start()
Regards!
Kinect sensor requires a lot of USB bandwidth so each Kinect should be connected to a separate USB controller. Try connecting both of them to different USB host controllers. You can also verify the status under "Microsoft.Kinect" node in Device manager.
I disabled the skeletal tracking and now both kinect sensors are running. But now the question that arises: Why it's not possible to enable also the skeletal tracking?

Accessing/monitoring battery status through SMBus

I am currenlty trying to monitor my battery status through SMBus.
I have a battery along with a control board that constantly outputs the battery status.
This control board is then connected to my mother board through a I2C-USB module.
I need to write a program to recognize the SMBus connection and transmit the battery status to the user.
I'm a beginner when it comes to dealing with smart batteries and I2C/SMBus, and I'm somewhat lost with how to approach this problem.
Any help of suggestions would be appreciated. Thanks.
Your question is a bit lacking. What kind of I2C-USB module? Or rather does it come with a Linux driver? If it does you probably won't need to write one. An application will do. You can read more about I2C and SMBus here.
Basically what you need is the I2C address of the control board (a single byte). When you have the address you (as the master) issue read commands over the I2C bus to the control board using its address and reads the response. If there's a driver for the I2C-USB module this should be straightforward enough. Plug in the device and open() the device (/dev/[i2c-usb-name] where [i2c-usb-name] is the name of the device). Then follow the driver implementer's guide how to setup and send data over that device (typically using read()/write() or ioctl()). Here are some additional information on working with I2C from user space: http://www.mjmwired.net/kernel/Documentation/i2c (select topics in the menu on the left hand side).
If you must write the driver yourself, the first stop for a Linux device driver beginner is the LDD3. Read it, it's quite a pleasant read.

Resources