I want to implement a P2P protocol in C for personal education purposes.
What would be the protocol with the shortest specification that is still used today?
I have already implemented a web and IRC client and server.
I agree with Mark, that point to point over a serial link would be a good exercise.
In particular, I would recommend the following programme of stuff...
Implement basic transmission over a "Serial Port" (using RS-232 if you have some Arduinos/embedded processors lying around, or using a null modem emulator if you don't (see com0com on Windows, or this on linux/mac).
I.e. send lower case letters from A->B, and echo them back as upper case from B->A
Implement SLIP as a way to reliably frame messages
i.e. you can send any string (e.g. "hello") and it is returned in upper case with "WORLD" appended ("HELLOWORLD").
Implement the "Read Multiple Holding Registers" and "Write Multiple Holding Registers" part of the Modbus protocol, using SLIP to frame the messages.
I.e. you have one follower (slave) device, and one leader (master) device. The follower has 10 bytes of memory that are exposed over modbus with the initial value "helloworld".
Just hard-code the follower / leader device Ids for now.
The leader reads the value, and then sets it to be "worldhello".
At the end of this you would start to have an understanding of the roles of network layers, ie:
The physical layer - Serial/RS-232
A "link layer" of sorts - SLIP
An "application" layer - Modbus
Serial. The answer is serial. You're not going to get any leaner than simple RX/TX communication but you'll lack a lot of convenience methods. If you want to explore more than simple bidirectional comms, I2C or modbus open up a lot of options.
Related
I'm dealing with the following challenge. In my system, there are two devices. Tags and anchors. Tags have BLE module with the transmit power 0dBm and not Long Range feature (BLE 4.0). Anchors have BLE module with transmit power over 8dBm and Long range feature (BLE 5.0).
I want tags to only receive some commands. Bi-directional communication is not necessary. This way, I can utilize the transmit power of anchor (8dBm) and thus quite bigger range, if tag with 0dBm is only receiving.
I read something about Observer/Broadcaster principle, where connecting is not necessary. But somehow devices have to agree on what frequencies should they hop on, the step and so on.
I'm asking, is it possible for device to only receive commands without previous negotiation with the sender?
Thank you very much for help. I'm beginning with BLE standard and there is a lot to learn.
Yes, it is possible to send data via adverts/scanning only. This way, there's no connection that needs to be established, and therefore no connection parameter negotiation takes place. As for the frequency hopping agreement - this happens via the baseband (in other words you will not deal with this in the software yourself) and is generally not applicable for advertising/scanning (these happen on 3 frequency channels only and therefore it is likely that the observer will catch what the broadcaster is broadcasting).
However, keep in mind that because you are broadcasting/advertising the data as opposed to directly sending it, that data can be received by any observing/scanning BLE devices which is not desired for safety/security/privacy purposes.
For more information on BLE communication, I recommend the links below:-
Getting Started with Bluetooth Low Energy
Is it Possible to Send Data with BLE Broadcast Mode
Using BlueZ, which
is the official Linux Bluetooth stack
I'd like to know which of the below two methods are better suited for detecting a device's presence in the nearby.
To be more exact, I want to periodically scan for a Bluetooth device (not BLE => no advertisement packets are sent).
I found two ways of detecting it:
1.) Using l2ping
# l2ping BTMAC
2.) Using hcitool
# hcitool name BTMAC
Both approaches working.
I'd like to know, which approach would drain more battery of the scanned device?
Looking at solution #1 (l2ping's source):
It uses a standard socket connect call to connect to the remote device, then uses the send command to send data to it:
send(sk, send_buf, L2CAP_CMD_HDR_SIZE + size, 0)
Now, L2CAP_CMD_HDR_SIZE is 4, and default size is 44, so altogether 48 bytes are sent, and received back with L2CAP_ECHO_REQ.
For hcitool I just have found the entrypoint:
int hci_read_remote_name(int dd, const bdaddr_t *bdaddr, int len, char *name, int to);
My questions:
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
shall I reduce the l2ping's size? What shall be the minimum?
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
To answer your questions:-
which of these approaches are better (less power-consuming) for the remote device? If there is any difference at all.
l2ping BTMAC is the more suitable command purely because this is what it is meant to do. While "hcitool name BTMAC" is used to get the remote device's name, "l2ping" is used to detect its presence which is what you want to achieve. The difference in power consumption is really minimal, but if there is any then l2ping should be less power consuming.
shall I reduce the l2ping's size? What shall be the minimum?
If changing the l2ping size requires modifying the source code then I recommend leaving it the same. By leaving it the same you are using the same command that has been used countless times and the same command that was used to qualify the BlueZ stack. This way there's less chance for error and any change would not result in noticeable performance or power improvements.
is my assumption correct that hci_read_remote_name also connects to the remote device and sends some kind of request to it for getting back its name?
Yes your assumption is correct. According the Bluetooth Specification v5.2, Vol 4, Part E, Section 7.1.19 Remote Name Request Command:
If no connection exists between the local device and the device
corresponding to the BD_ADDR, a temporary Link Layer connection will
be established to obtain the LMP features and name of the remote
device.
I hope this helps.
What are the properties of a wireless sensor node ?
From Omnet++ manual i came to know that
simple wirelessnode
{
gates:
input radioIn;
parameters:
...........
}
Though the node have only input gate , how it sending data to other node?
if the node is wireless how the sensor node connected ?
How to define a region around a wireless sensor node for reach another node in range?
Thanks
For sending, you can think with a DODAG : take a tree, put the root as the gate. The gate gathers the data of its children, each of those children gathring themselves the data of their children ... the leaves are the nodes that need the more hops to be reached from the root.
Here you would need, among others : the power of the transmitting, the power of the receiving chip (so that if the sending node is too far away then the receiving node won't catch its frame for example, as pointed by user4786271), a protocol to route them (so that if a node has 2 other nodes in range of rank n-1, to know which one it will use).
Try to dig into some open source WSN simulators implementing protocols, you could get a lot of info. For example : https://bitbucket.org/6tisch/simulator/src
To answer your exact question, there is no such thing like "general properties" for a given module when designing a protocol.
Usually the decision of the module properties that you are going to use, is strongly related to what that node is supposed to do as part of your protocol.
If your node is never going to communicate, there is no point in adding a gate to it.
Though the node have only input gate , how it sending data to other
node?
You don't have to strictly adhere to the design that you have seen. Maybe in that case the nodes only need to receive messages. In your case you might want to define an output gate.
if the node is wireless how the sensor node connected ?
Do not view the gates as physical entities, but rather as interfaces which are capable of communicating through links. Do you see a cable link between your mobile phone and the basestation? Probably not, because they are connected through a wireless link. So your mobile phone has an interface for wireless link. See where I am going? In your case you will need a gate with wireless link.
How to define a region around a wireless sensor node for reach another
node in range?
Hmm, based on your propagation model the received signal power will depend on the distance, right? You can check the received power for the MAC frame and dismiss it if it is below a given threshold.
Or, if you work on the application layer -- which you don't -- you can embed location information in your packets and then perform pairwise distance comparison to decide packets from which sender to consider or drop.
At work, we just got a large number exotic cellular devices that need to be programmed. To do this, you plug in a standard home telephone and dial a series of numbers, with pauses between them.
To me, this is a task that begs to be automated, and we've got one Linux desktop (a test Asterisk machine) with a modem on it.
So, how can I automate this task?
Simply send the necessary AT commands to your modem via the modem's corresponding /dev device, e.g. ATDT 12,456567,21
I think you should be able to open the modem device (often sym-linked from /dev/modem), and enter modem codes to reset the modem (atz, perhaps), then the codes to dial (atd), then the number, with "," for pause.
You can automate this in probably almost any language that allows you to write to the device file.
Take a look at the reference here:
http://www.zoltrix.com/support_html/modem/USEMODEM.HTM
My typical dial out string (all directed at the modem device):
ATZ (Dear modem, forget everything you knew)
ATS11=33 (I liked dialing fast)
ATF0 (Auto negotiate link speed)
ATL3 (I like it loud)
ATM3 (I only like hearing the handshake loudly)
AT&G(x) (In case you have a US modem and need to use it in the rest of the world (guard tone))
AT&K3 (hw flow control, if not available use software via AT&K4)
AT&R1 (CTS (clear to send) is always on. Wrapping RJ-11 connections in static free softener sheets helps this.
Finally, and most importantly:
ATDT (number) (Dial a number using DTMF) Depending on the age, your modem may support ATDP (pulse dialing).
Just keep in mind, +++ is an escape sequence, returning you to the modem console :) Have fun. +++ ATH0 and you hung up. ATH1 takes it off hook and does little else. ATA answers an incoming data call. Comma, , is a pause.
Yeah, others linked to the Hayes AT command set, I actually used it for years as a SysOp of a BBS :)
Finally, screw Kermit, use Zmodem.
Links: Synchronet, WWiV, the rest are an exercise for the reader, though I humbly suggest searching for Renegade, Telegard, TaG and others.
Oh dear, I'm off on a tangent.
If you need to pause and respond to replies back from the device - this is exactly what expect was invented for
Use the Hayes command set:
The following commands are understood by virtually all modems supporting an AT command set, whether old or new.
D Dial
Dial the following number and then handshake
P - Pulse Dial
T - Touch Tone Dial
W - Wait for the second dial tone
R - Reverse to answer-mode after dialing
# - Wait for up to 30 seconds for one or more ringbacks
, - Pause for the time specified in register S8 (usually 2 seconds)
; - Remain in command mode after dialing.
! - Flash switch-hook (Hang up for a half second, as in transferring a call.)
L - Dial last number
See Linux Modem-HOWTO for details.
I am designing an information kiosk and need a BT application which can automatically push a file to the nearest BT enabled device assuming that this would be the phone of the person currently standing in front of the kiosk.
Is there any other ways of doing this except by checking the RSSI (Received Singal Strength Indicator)?
Do all Bluetooth stacks support accessing this property?
How accurate is RSSI as the basis for the decision to which device to push to? Can it be that other phones which are further away from the kiosk can emit a stronger signal than the signal coming from the phone of the guy standing right in front of the kiosk?
Not all stacks support RSSI.
There's an alternate way: the device who first answers to Inquiries should have a stronger signal.
Your guess is true, it only depends on signal strength, not distance.
Also, the device with the stronger signal is not necessarily the one which answers first, since implementations of the protocol are different among devices. Thus you would have to test all target devices separately.