I want to know in RPL networks, after a node sends one packet to another node (for example RPL-Collect/udp-sender), how to know that intended node will forward this packet or not? I think overhearing neighbors transmission is needed, but is the another simple way to implemented this scenario in Contiki/Cooja?
To overhear packets in addition to normal operation you need to do several things:
Ensure that the radio is turned on and in the right channel. If you're using always-on CSMA or ContikiMAC you don't need to do anything special. Same for TSCH minimal schedule. Otherwise for TSCH you need to schedule a Rx cell with the right channel offset and in the right timeslot.
Somehow hack into the MAC layer to print or account packets not addressed to you - normally the MAC layer silently drops such packets.
Ensure hardware frame filtering is turned off (the radio is in promiscious mode).
Example:
radio_value_t radio_rx_mode;
/* Entering promiscuous mode so that the radio accepts all frames */
NETSTACK_RADIO.get_value(RADIO_PARAM_RX_MODE, &radio_rx_mode);
NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, radio_rx_mode & (~RADIO_RX_MODE_ADDRESS_FILTER));
If you just need to overhear packets and don't need the normal operation things and simpler. You can use SenSniff then.
Related
In the context of a DFU driver, I'm trying to respond with a packet of length zero (not ZLP as in multiples of max size, just zero bytes) to a USB control in transfer. However, the host returns with a timeout condition. I tried both, the dfu-util tool and the corresponding protocol, as well as a minimal working example with pyusb just issuing a control in transfer of some length and the device returning no data.
My key question is: Do I achieve this by responding with a NAK or should I set the endpoint valid but without any data? The specs are rather vague about this, imo.
Here are some technical details since I'm not sure where the problem is:
Host: Linux Kernel 5.16.10, dfu-util and pyusb (presumably) both using libusb 0.1.12
Device: STM32L1 with ChibiOS 21.11.1 USB stack (sends NAK in the above situation, I also tried to modify it to send a zero-length packet without success)
It sounds like you are programming the firmware of a device, and you want your device to give a response that is 0 bytes long when the host starts a control read transfer.
You can't simply send a NAK token: that is what the device does when the data isn't ready yet, and it causes the host to try again later to read the data.
Instead, you must actually send a 0-length IN packet to the host. When the host receives this packet, it sees that the packet is shorter than the maximum packet size, so it knows the data phase of the control transfer is done, and it moves on to the status stage.
I'm trying to implement S-MAC protocol on waspmote xbee sensors and i know it has its own CSMA/CA. So first of all I need to understand the basic of xBee collision avoidance.
Two senders set up in api mode in libraries and both periodically sending single bytes to a common receiver. I reduce the delay and many changing in libabries to make collision and to see how algorithm works. But when i monitor data at the receiver all looks as expected at the receiver .. byte1, byte 2 .. byte1, byte2.
Do u have any idea how can i make collision?
Are you sniffing the 802.15.4 traffic? That's the only way you'd see a collision.
The XBee module buffers the data you want to send, using the host communication parameters (baud rate, API mode, etc.) and then sends it out over 802.15.4 at 250kbps. The module has all of the collision avoidance built in, and will retransmit as necessary to deliver your message. If it's unable to deliver after some number of transmission attempts, you'll get a Transmit Status frame indicating failure.
On the receiving end, it buffers the data and delivers it to the local host using local serial settings (baud rate and API mode).
If you're trying to implement S-MAC, you need a different radio processor where you have low-level control over the radio. The XBee module provides an application layer and handles the MAC layer itself.
I'm currently working on a project which involves dealing with a HW device tailor-made for this purpose.
The device will serve the purpose of sending certain data via serial port (COM1, for instance). The data it is supposed to send doesn't matter that much.
I already have some knowledge regarding Windows serial port communication. CreateFile, WriteFile, and so on... BUT...
There is one "engine" on the device, which will send me the data when I ask it to, and in order to do so, I need to send there a signal (10101010) the rate of which will indicate the clock rate of that device "engine".
Here comes the explanation of how this device work. It gets a signal to send data through one pin. I'm supposed to send there 0 for start, 1 for end. Then, after this, it will watch some other pin for signal, sample it, and based on the frequency of ones and zeroes I send to it, it will start sending data via the thrid pin.
My questions are:
How to access individual pins of COM port?
How to manage the frequency and any delays I will need by myself?
I think that maybe I will have to do on this in kernel more by use of device drivers which will have to be developed.
There is an easier way. The COM port will send out the signal of alternating 1s and 0s if you just send a 0xAA byte.
I'm trying to implement a simple communication between two LPC1765 devices using RS-485. I'm using this example added to my menu system (it's a basic example for LPC17xx):
http://www.codeforge.com/read/155431/rs485.c__html
http://www.codeforge.com/read/155431/rs485.h__html
http://www.codeforge.com/read/155431/rs485test.c__html
So, both devices are properly initialized using RS485Init(). When I send data using RS485Send using a slave address as the first byte, the result is:
(1) if the devices are disconnected, transmitter receives its own communication (the contents of UARTBuffer are updated
(2) if the devices are connected, nothing happens -- transmitted buffer is lost somewhere (UARTBuffer doesn't change)
Now hardware should be properly connected so I'll just list things for reference. There is a U59 SN65HVD1781D driver on RS485_TXD/RXD, there are RS485_OF, RS485_MASTER_PWR and RS485_MASTER_MFAS and a voltage regulator. There is a RS485 slave detect circuit and UP/DOWN connections. Each device is connected with four contacts and they are (I think) RS485_UP, RS485_A+, RS485_B- and RS485_DOWN. There is a 4-pin connector both on top and on the bottom to connect devices in a sequence, where the topmost device would, if everything works, assume the status of a master over all bottom devices.
I got RS485 to work.
Using LPC17xx user manual at http://www.nxp.com/documents/user_manual/UM10360.pdf
In rs485.c in function RS485Init, direction control bits were wrong with PINSEL1 instead of PINSEL4; according to manual page 110, this should be correct (well, you can write 0x800 in many ways, but this is just a quick fix):
if (DIR_CTRL == 1){
LPC_PINCON->PINSEL4 |= 0x800;
LPC_UART1->RS485CTRL |= (RS485_DCTRL|RS485_SEL|RS485_OINV);
}else{
LPC_PINCON->PINSEL4 |= 0x8000;
LPC_UART1->RS485CTRL |= (RS485_DCTRL|RS485_SEL|RS485_OINV);
}
The second device has received my buffer.
I have a general question about Rs232 Software Flowcontrol (aka XOn/XOff)
The .Net implementation (and the nativ win32 api) bothe define a property called WriteTimeout / ReadTimeout, which is a time in ms after which a communication is considered to be overdue.
No my problem is this: If I send, lets say a 5 Byte string to the device I don't see any WriteTimeout, as expected. How is this implemented? Everything I find about Software flow control is that XOFF is to be set, when the recieve buffer is full; XOn when it is ready to recieve again.
But from the behavior I see, I would suspect, hat the device sends XON, after it has processed the 5-Byte information that I send, thus creating the information for windows to generate the corresponding events.
So when to send XON on a two-wire only RS232 implementation? Only if the buffer was full and to restart recieving; Or to signal, that we are "still ready" to receive after every chunk we processed?
How to implement?
Cheers & thx in advance!
Corelgott
Send an XON any time you are ready to receive data (your receive buffer is empty or nearly so). Send an XOFF any time you cannot accept more incoming data (your receive buffer is full or nearly so). The process is documented on the Wikipedia software flow control page.