I want to scan the signal strength received from 3 AP.
I would be happy if that could happen every 300ms (max.500ms). I flashed OpenWRT on the routers.
I was seeking for a good tool to do that.
First I found iwconfig which worked, but only with networks that I was connected to. So I used iwlist (iw didn't work- maybe I need to update it?). Do you know how accurate is the output of it? Can I trust it?
After that, I came across the IOCTL. It looks really powerful* and professional. But is the output from getting the signal stregnth from a WIFI more reliable than the simple method like iwlist/iw?
*even too much powerful as I failed to compile any program I wrote using it
If you want to determine the signal strength of WLAN access points to which you are not connected, scanning is the right way.
The scanning is performed by the wireless network card with much or little "help" from the driver, depending on the design of the wireless card. There are cards (chipsets, to be more specific) that have their own processor and run their own firmware code independently from the host computer. On the other end, there are "stupid" cards where the driver on the host computer does most of the work.
Between the driver and the rest of the operating system, there is an interface (API) for sending commands to the driver and reading back information in a standardized way. With Linux, there are at least two different APIs. The older one is named Wireless Extensions, and the newer one is named cfg80211. Normally, a driver supports only one of the APIs. Most current drivers use cfg80211, but there may be older drivers that still use Wireless Extensions.
For each of the two APIs, there's a user-space tool (or family of tools) to use it. For Wireless Extensions, there is iwconfig (and iwlist, iwpriv etc.) For cfg80211, there is just iw.
So, the questions about the right tool depends on what API the wireless driver uses. To add confusion ;-), cfg80211 does some emulation which allows you to perform some Wireless Extension calls to drivers that use the newer cfg80211 API.
Regarding your questions about ioctl(): This is a generic method for communication between user-space and kernel-space in Unix operating systems. The old Wireless Extensions API uses ioctl(). The newer cfg80211 API does not use an ioctl()-based interface, but uses nl80211 instead.
To sum it up: whether to use iw/cfg80211/nl80211 or iwconfig/Wireless Extensions/ioctl depends on the driver or your wireless card.
Regarding your desired scanning interval, I would say that 300ms is rather short. This is because for a useful scan, the client needs to leave its current channel for a short time, switch to another channel and listen to signals from other access points on this channel. Since leaving its channel interrupts communication, these off-channel times are usually kept short and are carried out infrequently.
Calling iw <dev> scan or iwlist <dev> scan, respectively, will not necessarily cause a new scan, but may return an old (cached) list of access points. Depending on your wireless card/driver it may be (im)possible to enforce a new scan.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
Over the last couple of years I have been looking for an easy way to control a few relays from Javascript. I want to build a web App to control starting sequence horns for sailing races.
I recently discovered webUSB and it seems like exactly what I need. A direct connection from JS in chrome to the USB world. Simple coding in a language I already use.
On the hardware side I am having trouble finding a product that is compatible. Googling USB Relay finds 100's of products that all seem to rely on some proprietary SW for the OS. I can find lots of educational demo's that turn an LED on and off.
Does anyone have any ideas where to find such a product?
While I'm sure you will be able to find USB relays that can be controlled via WebUSB, most USB relays will probably come with some kind of serial port driver, e.g. https://numato.com/product/1-channel-usb-powered-relay-module uses a CDC serial port driver. These can be controlled using Web Serial, available in Chrome 77 and later behind a feature flag. For a tutorial, see https://codelabs.developers.google.com/codelabs/web-serial/
Explainer: https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md
API docs: https://wicg.github.io/serial/
If you search for "5V USB Relay Programmable Computer Control For Smart Home" on eBay, you will also find low-cost relays that use HID instead. The advantage of these is that you don't need any serial port or USB drivers, as it will use the operating system's built-in HID drivers. For that you can use WebHID. For more info, see https://github.com/robatwilliams/awesome-webhid.
I am designing a USB keyboard with special capabilities. What information can such a HID device receive from the host?
Can I via USB:
Read data from a form on the screen?
Find out what OS the user is on?
Find out if there's been an error message?
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen?
Thank you!
The device can't get any of this information from a standard driver that the operating system supplies because that would be a security issue. It can receive any information that your own driver or application sends it. There are many ways to communicate with it - your device could present multiple interfaces (which will appear as separate devices), multiple endpoints, or use the control channel. You will definitely need to study the spec, and I also found this tutorial helpful.
I have done something similar and used the control channel to exchange feature data with a Windows application (over the standard Windows driver). On Windows, the API calls are HidD_SetFeature() and HidD_GetFeature().
On the device side, my hardware ran embedded Linux and I used the GadgetFS library to create a user-mode driver - much easier to debug than a kernel driver.
As others have said, you'll run into issues if you try this with a normal HID. However, there is a project called the USB Rubber Ducky. From their description:
The USB Rubber Ducky isn't your ordinary HID (Human Interface Device).
Coupled with a powerful 60 MHz 32-bit processor and a simple scripting language
The USB Rubber Ducky looks like a usb-device and is recognized as a HID, but is programmable. You can make a small script that will be typed onto the screen which will allow you to performs the queries you seek.
With the USB Rubber Ducky you can:
Read data from a form on the screen? Yes
Find out what OS the user is on? Yes
Find out if there's been an error message? Yes
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen? Yes
If you aren't hoping to buy this device, at least their firmware is on github so it can provide you a starting point
I am very interested in device driver programming .I have started reading the LDD3 ,there author said
"to become a device driver programmer you have to understand your specific device well"
can any one tell me what is the meaning of the "understand your specific device" .what are the thing I should know before writing a device driver.
Thanks
That's a basic list with software and hardware combined.
The Operating System driver API
The processor architecture as it relates to hardware interfacing
The 'bus' structure that interfaces the device hardware to the processor
Interrupt Handling
Dma Control
Processor Caching
Processor MMU control
OS Semaphores and scheduling
Data/Byte Alignment
Assembly language when needed
Control of Instruction Execution Order and Optimization
Consideration of performance issues
What's IO and memory mapped hardware ?
http://www.cs.nmsu.edu/~pfeiffer/classes/473/notes/io.html
This link talks about generic hardware access in Linux device drivers.
http://www.linuxforu.com/2011/06/generic-hardware-access-in-linux/
This is specifically about USB hardware
http://www.beyondlogic.org/usbnutshell/usb2.shtml
Check lwn.net it never disappoints a device driver developer.
https://lwn.net/Archives/
Last, but not least, They have everythig, CPU, Memory, Camera, PCI..
http://www.hardwaresecrets.com/page/memory
-
Hi, I'm very pleased to share what I have learnt with you guys.
Yes, it is the basic need to know your device if you wanna be a device driver programmer. I also want to be a linux device driver programmer, or even more, though I have some device driver experience under other software platforms.
The reason why you wanna contact with it is that you wanna make it do something for you.
Normally, what it can do is the first thing you must know. It's very obvious that you will never send Ethernet frames through UART or SPI, right?
There exist various kinds of devices in the world, such as, storage device, FLASH, SD card, harddisk; communicating devices, network card, wifi; interconnected bus, PCI-express; how many there are.
After that, the next thing you will concern is how you can do to reach your goal.
To access the device, reading, or writing, there is usually a controller embedded in the processor. Here, when I say "processor", it means it is a core integrated with various kinds of controllers, no matter pc desktop or embeded system areas.
The Controller is the interface you will face, to work on the device behind the controller.
Through the controller, you can ask the device to do what you want. In the controller, there are registers, which are the deepest points the software can touch. Beyond that lies the hardware, as you are a device driver programmer, it is very common for you to communicate with hardware engineers to make things done.
If going into details about the register, there are control registers used to tell device what you want it to do, status registers, used to reflect the status of operations underway in devices, if interrupt is supported by that device, there are also some registers for you to deal with interrupts.
Well, I almost forget there are also data registers, whicha are used to store the data to be sent or written, or to be read by user. According to the specific implementation, registers used to store data from upper users to be sent or written and registes used to hold data from outside that will be read by users may be the same, or may be not.
In a normal way, if you wanna let someone do something for you, you should provide something to him first. Whoever wants to do anything, there must be some inputs to him, right?
in a summary,
action(read,write,or others) + data(you give, or you ask for) + status(what progress it is)
what it can do
how it does that, how to assemble the command cell, time sequence?
what you must provide it to reach your goal
genarally, two kinds of things you should provide:
if you ask for, where to store what you ask for;
if you give, where are what you give
how it reflects the progress of operations， polling or interrupts
Well, that is all I want to share with you.
Thanks.
My colleague and I are mining the GPRS MODEM market for a module suitable for use with embedded Linux. During the market scan, we see that several vendors highlight that their MODEMs include an embedded TCP/IP stack.
This makes me wonder: when we are using embedded Linux which already contains a TCP/IP stack and connects using PPP, will it make use of the stack included in the GPRS MODEM at all?
My current assumption is that the stack is included for use with tiny microcontroller OS that do not supply their own stack. Also some of the MODEMs allow for running small applications IN the MODEM baseband processor which could explain the embedded stack...
So: is the TCP/IP stack supplied by the GPRS MODEM superfluous when using it with an HL OS or did I overlook something?
It is almost certainly superfluous in your use case.
Most cellular modem products are cut-down versions of products designed for use in mobile phones. Obviously, in a phone application, the TCP/IP stack is required, along with a whole pile of other functionality.
A typical GPRS modem probably contains an ARM9 processor, and this is not greatly taxted running just the modem software. For many smaller applications it certainly provides sufficient performance to run the entire application (think of something like a vending machine indicating that it is nearly empty, for example), and a TCP/IP stack might be helpful here.
There is a slightly cynical possible explanation, too. Many mobile phone stacks have a bit more software coupling than their manufacturers would like to admit to, and it may turn out that it is simply not worth the effort to remove the TCP/IP stack.
In your application, it is almost certainly the best option to use the AT command interface (this is an extension of old-fashioned dial-up modem command set to allow you to fetch information such as signal strength, network status etc.
This is the EXACTLY same question I been asking myself these two days. ^^
After some study and asking around, I found this:
In the case of a smart phone such iPhone/android, TCP/IP are running on Application Processors(AP) as part of the OS. Baseband Processors(BP) are simply network modems (think of the 56k dial-up modem and PC setup in ancient time). Of course BP will be running mobile network stack(GSM, CDMA, LTE...) to hop on cellular network, but to AP, it's transparent and simply does modulation/demodulation work for the wireless network. Modems receives AT commands and can switch between command mode and data mode in operations. In data mode, the protocol between AP and BP is normally PPP over serial (! correct me if i am wrong here). So TCP/IP/PPP/serial.
Embedded TCP/IP stack found in some BP are meant to provide an entire abstraction for certain applications whereby network stack is not available due to system constraints or simply made to be simple. A TCP/IP stack is then very useful in BP. As you mentioned, some BP (e.g infenion) does have extra processing power for user application and/or network stack. AP, in this case, is even not needed. This is a typical setup of a function phone(such as Nokia brick). Extension of AT command sets are then provided by BP to create a socket or even a FTP connection.