I'm developing a forwarding protocol using Contiki OS. The protocol is running on top of IEEE802.15.4 TSCH mode. The protocol requires to add a certain amount of packets during a short period of time very often I get following error:
[RLL]:Send to Parent 0 base timeslot: 40, currentTimeslot: 1, send timeslot: 45 at: asn-0.46c41d
TSCH: send packet to 255 with seqno 0, queue 0 1, len 8 120
[RLL]:Send to CS base timeslot: 40, currentTimeslot: 2, send timeslot: 50 at: asn-0.46c41e
TSCH-queue:! add packet failed: 0 #0x20003004 8 #0x0 #0x0
TSCH:! can't send packet to 255 with seqno 0, queue 1 1
While it adds the first packet, it can't add the second packet. The queue is not full, i checked that.
The error simply says, its not possible to allocate memory for another packet, while there should be more than enough space.
Probably its just a simple setting i oversea but I can't find it.
If anyone has a suggestion, please let me know.
Conrad
Related
I have the following setup:
A FPGA sending out data on UART at a baudrate of 3Mbps. The data transmitted is a chunk of 1024 bytes sent at a variable periodicity ranging from 20ms to 200ms. (So even in the worst case, datarate is far from 3Msps)
A FTDI 232RG
A piece of python running on my computer (Windows), doing basically : opening a COM port with pyserial, 3Msps, polling the in_waiting until it reaches the size of a packet (1024 bytes), formatting the packet received and print it on the screen
The script works well for low repetition frequency, but I face issues with higher repetitions (typically 20ms). When the periodicity in 20ms I eventually end up getting a buffer overflow somewhere before the in_waiting. I checked the timing of my python loop and it takes about 4ms. So it looks like there is something upstream (in the FTDI or Windows) that feeds the pyserial buffer with more than one packet within the 4ms following a packet.
I tried changing the FTDI latency in the driver (from 16ms default down to a few ms) but it does not seem to help.
I am currently clueless about what is happening. Would you have any advice about how to understand better what is happening?
Thanks for your help!
You could create a "loop" between TX and RX and run the following code (tested with a FT2232H, so mostlikely you need to change the identifier string):
import time
import serial
import serial.tools.list_ports
print([(x[0],x[2]) for x in serial.tools.list_ports.comports()])
port = [x[0] for x in serial.tools.list_ports.comports() if "FT4Q1LJFB" in x[2]][0]
ser = serial.Serial(port,12000000)
while True:
t0 = time.time()
counter = 0
for i in range(1000):
ser.write([1]*3000)
recv = ser.read(ser.inWaiting())
delta_t = time.time() - t0
counter += len(recv)
print(counter / delta_t)
For me the following output is shown
[('COM7', 'USB VID:PID=0403:6010 SER=FT4Q1LJFA'), ('COM8', 'USB VID:PID=0403:6010 SER=FT4Q1LJFB')]
0.0
0.0
0.0
0.0
96787.81184093593
1201991.0268273412
1201197.0857713912
1201166.9350959768
1201445.4072856384
You will notice that it is 0.0 in the beginning. This is because I connected RX and TX after starting the program resulting in a ramping up of the received bytes. This is the "default" mode meaning 8 bits + 1 start bit + 1 stop bit = 10 bits per word which explains why "only" 1.2 Mbytes per second are transmitted.
I am using a SIM800L module with a Texas Instrument Launchpad, with a MSP430G2553 microcontroller, not using an external library for SIM800L.
Problem Statement:
A Simple text message (SMS with Text Mode) is sent, received as a blank message on cellphone.
SIM details:
1. SIM 1 : Location: India. Operator: AirTel, 4G compatible SIM Card.
2. SIM 2 : Location: India. Operator: Tata Docomo, 3G compatible SIM card.
What I know already:
UART Drivers in firmware are tested and working, non-polling, interrupt driven.
No blocking time delays added as a substitute to read responses of AT commands. I read the response and proceed only if positive acknowledgement is received, <CR><LF>OK<CR><LF> for most of the commands.
I have confirmed the data bits transmitted and received on Tx-Rx pins by means of an oscilloscope. Everything seems as expected, including voltage levels.
What I have read:
Some speculation through unofficial sources (Of course forums) that SIM800L is only 2G compatible.
(Shallow reading from wikipedia) I have read through GSM 3.38 and GSM 3.40, and the Data Coding Scheme section for understanding how the encoding of text is handled in suited/relevant AT command (AT+CSMP).
Various forums including the ones for arduino with which SIM800L modules are very popularly used.
Related posts on Stackoverflow:
Recieving Blank SMS SIM800 using AT Commands and Python on Raspberry Pi 2
How to send SMS with GSM module SIM800 and Arduino Uno?
Sending GSM Character Set in SMS with SIM800L Module
The answer in the first one seemed to have worked for him, it didn't work for me.
What have I tried:
I have used the same module with an instance of Docklight serial terminal. SMS sent from Docklight are received on my cellphone and appear as expected, not blank.
On day 0, before integrating module with Launchpad hardware, I have tested the overall firmware state machine with exact copy of expected responses from SIM800L.
The results for both the SIM cards are same, except for some of the initial configurations, but I load a typical set of configuration in both of them before I initiate any SMS related task.
Typical values that I use are:
Echo Off
CSMP: 17, 167, 0, 0 (I have tried 17, 167, 0, 0, but no luck). Default from SIM 1 is 17,11,0,246, and that from SIM 2 is 17, 255, 0, 0.
CSCS: "IRA"
Failed combinations on serial port: (SIM 1 and SIM 2)
CSMP: 17, 11, 0, 246 | CSCS: "IRA" - Sends a blank SMS
CSMP: 17, 11, 0, 246 | CSCS: "GSM" - Sends a blank SMS
CSMP: 17, 11, 0, 246 | CSCS: "HEX" - Sends a blank SMS
Successful combinations on serial port: (SIM 1 and SIM 2)
CSMP: 17, 167, 0, 0 | CSCS: "IRA"
CSMP: 17, 167, 0, 8 | CSCS: "IRA"
CSMP: 17, 11, 0, 0 | CSCS: "GSM"
CSMP: 17, 167, 0, 0 | CSCS: "GSM"
CSMP: 17, 167, 0, 8 | CSCS: "GSM"
To be honest, I played hunch with these combinations before I studied what field reflects what change these combinations (which are poorly documented in the SIM800L User guide).
Any idea what I might be missing here? I am open to thinking that it is more of a RTFM (Read The Fat Manual) issue.
Ok, managed to resolve the issue.
It was not about the SIM800L at all.
The whole payload was followed by a '\0' which is unexpected (I know, very poor on my side). The serial term has no issues with it whatsoever.
Debugging was fun!
I'm using esp8266 with the firmware produced with Marcel's NodeMCU custom builds http://frightanic.com/nodemcu-custom-build/
I tested the "dev" branch and the "master".
I changed a little bit the "Connect to MQTT Broker" code found here https://github.com/nodemcu/nodemcu-firmware
-- init mqtt client with keepalive timer 120sec
m = mqtt.Client("clientid", 120, "user", "password")
m:on("connect", function(con) print ("connected") end)
m:on("offline", function(con) print ("offline") end)
-- m:connect( host, port, secure, auto_reconnect, function(client) )
-- for secure: m:connect("192.168.11.118", 1880, 1, 0)
-- for auto-reconnect: m:connect("192.168.11.118", 1880, 0, 1)
m:connect("192.168.11.118", 1880, 0, 0, function(conn) print("connected") end)
-- publish a message with data = hello, QoS = 0, retain = 0
local i = 1
while i < 10 do
m:publish("/topic","hello",0,0, function(conn) print("sent") end)
i = i + 1
end
m:close();
I'm using mosquitto as a mqtt broker and I have launched a subscriber on all topic #.
The result is: the messages arrives correctly but they are really slow to arrive on the subscriber (around 1 second each)... why?
I tried also to change the mqtt architecture in favor of UDP.. the esp8266 send the 100 messages fast.
UPDATE 1#:
I have done some more experiments:
Testing the broker and the
subscriber with an [android phone + a mqtt publisher], the subscriber
receive messages immediately
I loaded a nodemcu with "debug" enabled
and I have done an interesting discovery: read on
For what I have understood reading debug log and source code..
There is a sort of queue that saves the messages in memory and a timer (I don't know the frequency/interval) reads a message from the queue and it sends it through mqtt.
If you try to send 100 messages, the queue increases, but it is not able to deliver messages at the same time (maybe there is a race condition? ).
There is a second problem here, after it has enqueued more than 15 messages, the firmware crash and the device reboots: it seems a symptom of memory no more available.
It may not be the answer you're looking for but yes, NodeMCU MQTT uses an internal queue for messages. It was added at the end of March 2015. It was added due to the asynchronous nature of the NodeMCU API.
If you have two calls to m.publish in quick succession, remember they're asynchronous, there isn't enough time for the 1st message to be delivered before the 2nd is triggered. Before the introduction of that queue the firmware would simply have crashed if you had published in a loop.
I simplified your code even more and added some debugging statements:
m = mqtt.Client("clientid", 120, "user", "password")
m:connect("m20.cloudmqtt.com", port, 0, function(conn)
print("MQTT connected")
for i=1,10 do
print("MQTT publishing...")
m:publish("/topic", "hello", 0, 0, function(conn)
print("MQTT message sent")
print(" heap is " .. node.heap() .. " bytes")
end)
print(" heap is " .. node.heap() .. " bytes in loop " .. i)
end
end)
Knowing that the calls to m.publish are asynchronous the output shouldn't be too surprising:
MQTT connected
MQTT publishing...
heap is 37784 bytes in loop 1
MQTT publishing...
heap is 37640 bytes in loop 2
MQTT publishing...
heap is 37520 bytes in loop 3
MQTT publishing...
heap is 37448 bytes in loop 4
MQTT publishing...
heap is 37344 bytes in loop 5
MQTT publishing...
heap is 37264 bytes in loop 6
MQTT publishing...
heap is 37192 bytes in loop 7
MQTT publishing...
heap is 37120 bytes in loop 8
MQTT publishing...
heap is 37048 bytes in loop 9
MQTT publishing...
heap is 36976 bytes in loop 10
sent
heap is 38704 bytes
sent
heap is 38792 bytes
sent
heap is 38856 bytes
sent
heap is 38928 bytes
sent
heap is 39032 bytes
sent
heap is 39112 bytes
sent
heap is 39184 bytes
sent
heap is 39256 bytes
sent
heap is 39328 bytes
sent
heap is 39400 bytes
You see that the available heap space is decreasing while publishing and increasing again as the queue is emptied.
I was told to ask this here:
10:53:04.042608 IP 172.17.2.12.42654 > 172.17.2.6.6000: Flags [FPU], seq 3891587770, win 1024, urg 0, length 0
10:53:04.045939 IP 172.17.2.6.6000 > 172.17.2.12.42654: Flags [R.], seq 0, ack 3891587770, win 0, length 0
This states that the flags set are FPU and R. What flags do these stand for and what kind of exchange is this?
The flags are:
F - FIN, used to terminate an active TCP connection from one end.
P - PUSH, asks that any data the receiving end is buffering be sent to the receiving process.
U - URGENT, indicating that there is data referenced by the urgent "pointer."
R - RESET, indicating that a packet was received that was NOT part of an existing connection.
It looks like the first packet was manufactured, or possibly delayed. The argument for it being manufactured is the urgent flag being set, with no urgent data. If it was delayed, it indicates the normal end of a connection between .12 and .6 on port 6000, along with a request that the last of any pending data sent across the wire be flushed to the service on .6.
.6 has clearly forgotten about this connection, if it even existed. .6 is indicating that while it got the FIN packet, it believes that the connection that FIN packet refers to did not exist.
If .6 had a current matching connection, it would have replied with a FIN-ACK instead of RST, acknowledging the termination of the connection.
I need to receive full packet from other IP (navigation device) by TCP/IP.
The device has to send 966 bytes periodically (over one minute), for example.
In my case first received buffer has length 256 bytes (first piece of packet), the second is 710 bytes (last piece of packet), the third is full packet (966 bytes).
How to manual set minimal value for first received buffer length?
This is piece of my code:
Executor bossExecutors = Executors.newCachedThreadPool();
Executor workerExecutors = Executors.newCachedThreadPool();
NioServerSocketChannelFactory channelsFactory =
new NioServerSocketChannelFactory(bossExecutors, workerExecutors);
ServerBootstrap bootstrap = new ServerBootstrap(channelsFactory);
ChannelPipelineFactory pipelineFactory = new NettyServerPipelineFactory(this.HWController);
bootstrap.setPipelineFactory(pipelineFactory);
bootstrap.setOption("child.tcpNoDelay", true);
bootstrap.setOption("child.keepAlive", true);
bootstrap.setOption("child.receiveBufferSizePredictorFactory",
new FixedReceiveBufferSizePredictorFactory(2048)
);
bootstrap.bind(new InetSocketAddress(this.port));
No matter what receiveBufferSizePredictorFactory you specify, you will see a message is split into multiple MessageEvents. It's because TCP/IP is not a message-oriented protocol but a stream-oriented one. Please read the user guide that explains how to write a proper decoder that deals with this common issue.