How to change the LED toggle speed in Contiki? - contiki

Im trying to implement a UDP client mote using cc2650 launchpad and I need to modify the code to toggle the led once a "hello message" is sent. The normal leds_toggle( ) command works but it takes a long time to turn of the led once it lit. How to solve this problem? Any Ideas?

Related

Possibility of Hack-rf one working on full duplex mode

I am working with hack-rf one and GNU radio. I have one hack-rf one device and i am trying to transmit and receive signals continuously. Is there any module in GNU radio which makes it possible?
Currently i have a flowchart for receive and one for transmit.
I am using selector block but manual switching isnt working properly.
I need to send and receive the same signals after reflection and study the difference.
Any suggestion is welcomed.
Since that is physically impossible for the device: No, no software on this earth can do that for you.

Receiving data using aux cable on GNU RADIO

I am transmitting and receiving data using aux cable and GNU RADIO between two laptops.
I have implemented DQPSK using PSK mod block.
The problem is that while receiving I have to provide a delay, some integer value e.g 0,1,2 etc.
It is different every time.
Is there a way to dynamically check for the right delay value or any other workaround to this situation?
I have written 'start.' at the start of data being transmitted and 'end.' at the end.
I have to give a demo for this project and I dont want to manually change the delay at runtime.
I cannot find the .cc file of file sink in GNU RADIO, I can change the C++ code according my requirement but there is no such file.
Below is the screenshot of the grc file on the receive side.
Any help will be appreciated.
Since there's no way for the receiver to know when the transmitter started transmitting, it decodes stuff before there's actually anything to decode.
In essence, you need some kind of preamble or so to tell your receiver when to start – side effect of having something like that would be that you could correct some things (the two sound cards don't share the same oscillator, which leads to a symbol rate offset, and a center frequency offset).
You basically added that framing - your start. and end. strings.
I cannot find the .cc file of file sink in GNU RADIO, I can change the C++ code according my requirement but there is no such file.
It's in gr-blocks/lib; however, you shouldn't modify the file sink. Really,
I'd recommend you take the time to go through the guided tutorials, use gr_modtool to generate a general block which has a state machine that looks for the bits of your start string and drops everything before and including those, and then passes everything till it sees the stop string. That all can be done with a single state machine, and a bit of python or C++ code.

HLK-RM-04 - http response are not clear

Currently, i'm working with HLK-RM-04 wifi to UART module. I'm using this in server mode. I've connected this module(tx/rx) to my PIC16F887. Connections are fine and I can able to transmit and receive data.
All i'm doing here is giving a html request from a browser/web client, and i'm expecting my data(responded from my MCU) to be displayed in browser. But i'm not getting it properly. Sometimes it works in right way, but most of the time if displays some junk value.
To analyze from MCU side, i tapped my MCUs Tx pin and connected to PC COM port. Yes, it seems it works perfect. I can able to see my data in hyper terminal, what i'm transmitting from MCU.
So to analyze from PC side, I used a free web-sniffer. There I can see data received was junk at sometimes. (Pls refer images) I couldn't able to guess whats wrong ?
Data sent to wifi module from MCU was right, but data sent from wifi module as wifi frames are bad ?
Is that any way to analyze further ?
Expected response - 1 out of 5 request wins:
bad response 2:
I don't remember when I was using HyperTerminal for the last time and I am not sure will it show whitespace characters (if I remember there is such settings).
One of the things that I would try is to install serial port sniffer or some advanced terminal (like Realterm) and verify that there is no some junk in form of white space characters that are hidden in HyperTerminal.

Does a CAN bus device need to be kick started to start sending messages?

I am a complete CAN bus newbie. I'm hoping someone with CAN experience can point me in the right direction. I was given a Vector VN1610 USB to CAN adapter and a Continental ARS-308 radar sensor. The goal is to read some velocity and distance information from the sensor. Right now I am just trying to see any data but all I get are messages with an id of 0 or 0x80000000. The data payloads all report as 8 bytes of 0.
What Works
I have been able to use the sample .NET code provided and set up the VN1610. The ARS-308 has a single CAN channel so in the Vector Hardware Config for my application I just map "CAN 1" to VN16101 Channel 1. (I leave CAN 2 unassigned) I then assume I use that one channel for both transmit and receive. The code reports that the channel sets up an activates and no errors are reported.
I then have a thread looking for incoming messages. If I don't debug out the two IDs mentioned above I can actually process all of them and then I get XL_ERR_QUEUE_IS_EMPTY messages. So it looks like its all working, I'm just not getting any real data.
What Doesn't
I would think a slew of data messages in the 0x200 - 0x702 range would be coming in for the Continental ARS device. Now I'm more used to ethernet type protocols where I would send a command and then read a response. None of my docs talk about how CAN works so I am ASSUMING that in CAN the device just sends data. I certainly can't find any commands that tell the device to send me the particular msg ID I'm interested in.
Am I missing some basic CAN configuration step that informs the device it should start sending data? Any suggestions at all would be appreciated.
If it matters I'm writing in VS2013, .NET on a Win 7 64 Ultimate machine.
The answer is No. It turns out that CAN devices will indeed just start streaming out messages when you turn them on (well at least this one does). The messages with ids of 0x0 and 0x8000000 are bogus. Even with the radar sensor turned off I continued to see those messages.
It turns out I had a hardware problem. The CAN bus requires a 120 Ohm resistor which was installed. The problem was when the shell was put back on the cable the resistor got cracked. Once we repaired this, everything started working as expected.

PIC32 becomes unresponsive after a few hours

I have a PIC32MX340F512 board developed by another company for us, The board has a DS1338 RTCC and 24LC32A eeprom, and display unit on an I2C bus, on this bus i included a TSL2561 I2C light sensor, i wrote code in c to poll the light sensor continously , when the light sensor reaches a certain level i save the time and date and light sensor value on SD card. This all works fine but if i leave the system without exposure to light inside tunnel where incident light on one end of the tunnel is ought to be monitored the system becomes unresponsive no matter how much amount of light you apply and then if i switch power off and back on again everything starts to work normal. i am a one man development team and have been trying to find out the problem for months, i activated the watchdog timer to prevent the system from hanging but the problem still persisted. i then decided to find out if the problem is with the sensor by including a push button to activate light measurement but still when 4-5 hours elapse the PIC cant even detect a change in the the input pin. Under the impression that a hardware reset overrides anything going on i included a reset button and it also works ok for the first few hours after that the PIC doesn't seem to be responding to anything including a reset. I was getting convinced that there is nothing wrong with the firmware but also with all this happening the display unit (pic16f1933 and lcd) on the I2C shares power with the main unit and doesn't seem to be affected as it alternates between different messages constantly Does anybody have an idea what could be wrong (hardware/firmware or my sensor). I am using a 24v DC power supply purchased seperately. The PIC seems to go into a deep sleep although i dd not implement any kind of SLEEP mode in my code. Nb We use the same board for many other projects and i haven't come across such a problem . Thanks in advance.
I think you need to (if you haven't already) explore the wonderful world of in-circuit-debugging (such as with the ICD3 or PICkit 2/3). It allows you to run the processor in a special mode that lets you pause execution, see exactly which line of code is being executed, inspect variable values, and step through the code to see which parts are running and not running, or see exactly where execution takes a wrong turn. If the problem takes hours to reproduce, that's okay. You can just leave it overnight running in debug mode and hopefully it will be locked-up or 'sleeping' in the morning. At this point, you will be able to pause the processor and poke around to see if you got caught in some kind of infinite loop or something. This is often the only way to dig inside a running piece of code to see why things aren't working as you expect. But as you say, those bugs that take hours or days to manifest are the trickiest. Good luck!
It sounds like you can break up your design into two main parts, sd card interfacing, reading the rtc and reading the light sensor. If it were me I would upload a version of the code that mimics reading the light sensor but only returns fake data and see if that cures the problem. Additionally do the same with the other two modules separately and see if any of the three versions of your project not show this problem. From there just keep narrowing it down until you find the block of code thats causing problems.
if Two or more versions of your debug code show the same problem then my guess is it has to do with one of the communication protocols. I had a problem with a Pic32 silicon version blocking when using the DMA in conjunction with the SPI peripherals. So I would suggest checking the errata for your chip.
If you still cant find the problem, my only suggestion would be to check for memory leaks or arrays that are growing into reserved memory.
Hope that helps, good luck!

Resources