I have an Arduino Uno connected to a PC via USB and I am communicating via serial to a temperature sensor from PHP.
At present, the temperature sensor records a value and sends it straight down the serial connection to the PC. However, this may not be read for a long period of time. Therefore, I think this method may be inefficient.
I was thinking I could listen on the Arduino for a serial message from the PX requesting the temperature before actually checking it and sending the message back to the PC via serial, therefore becoming more efficient as its not checking the temperature every 0.1 seconds.
My Questions are as follows:
Is this actually worth doing from a code efficiency point?
Is there a better way to improve this than my suggested method?
Would these changes improve battery performance (Eg if I was using a
different communication model and not Serial and therefore might
need a batteries)
A1: Since you already have the routines to measure the temperature and then send it to the PC there should not be much coding left to do to wait for a trigger from the PC before performing the routine.
A2: There always is a 'better' way :)
A3: If your µC does not have many other tasks to perform that keep it busy you can definitely save a lot of juice by putting the µC to sleep between those short periods of activity - which you should do anyway when running off batteries.
Related
I just wanted to know, what is more efficient
Using NTPClient library and making an http request to get the time.
Using a RTC and read the time from it.
Taking into account that I used deep sleep, and once it wakes up has to set up the wireless because I am sending data into cloud storage, but just before I get the time with the NTPClient library.
But I am thinking that I may save some battery if I use a RTC.
What do you think?
Thanks
I'm starting to work on a project that use both RTC and NTP running on battery and using deep sleep.
The advantage of using RTC module (in my case with i2c protocol) is that to get the time you need tens of ms, instead of using NTP for which you need 1 or 2 seconds at least depending on the library used.
Furthermore, the use of an RTC module is much more reliable as there is no possibility of connection problems or anything else. During my tests the RTC module has never failed, on the contrary, the wifi/internet/ntp connection sometimes has failed.
The RTC module can be programmed offline and then mounted in the circuit. It has a back-up battery that should guarantee a duration of a couple of years (like a wristwatch). In my case (as also recommended by Marcel Stör) I will use date and time coming from the RTC module and only once a week I will try the calibration using the NTP protocol.
At last but not least, keep in mind that many iot cloud platforms accept only the data and as a timestamp use that of receiving stream itself and not one provided by the device.
Then, for battery saving (and reliability), is better to use RTC.
I've been trying to establish serial (UART) communication between a Raspberry Pi Model B Revision 2.0 (checked the model like described on this page) and Arduino Mega 2560. I made a service on the Pi that writes to UART and then expects a message and a coworker programmed the Arduino with an echo program. While they were communicating, I had trouble receiving data, meaning that it was clustered in 8 byte pieces and I had to introduce a timeout for waiting between them (I was actually as much as available and calling select()for the next cluster but it turned to be 8bytes a cluster, except for maybe the last one. As explained in a question I found on this site, the programmer is the one to take care of the protocol and can not rely that the whole message will be ready to read at once (that is logical).
However, when I just connected Pi's TXD and RXD pins, no matter how much bytes I tried sending, it sends them in one go (I've gone up to a bit more than 256, that's more than enough for my purposes). I also have around 50 milliseconds of duration difference, measured directly from within the program, using gettimeofday() function.
So, could anybody clear things for me:
Why is this happening?
Is this difference in behaviour expected?
Is there a potential problem in either of the devices (if that can even be concluded from the given information).
Of course, any additional information is welcome, in case I forgot asking something that is deemed important.
Why is this happening?
I tried some time back communicating Arduino-Arduino and Arduino-Pi. I faced some problems with UART communication. However, you might want to keep same Baud rate on both the devices. With Pi, you might need to trigger an event if you receive data from Arduino. On the other side, if you code runs longer, then you might lose some data i.e. your Arduino code is running something else while Pi sends data over UART.
Is this difference in behaviour expected?
Yes. Arduino is a microcontroller based device while Pi is microprocessor based (runs on OS)
Is there a potential problem in either of the devices (if that can even be concluded from the given information).
I don't think there could be any hardware problem unless it is not functioning at all.
Also, because of this issues, I switched from UART communication to SPI communication. This solved my problem completely.
I am using an Arduino Pro Mini 328P (3.3v, 8Mhz) with Xbee series 1. I have set the frequency to 1 Mhz and the baudrate to 9600. Also I have set baudrate to 9600 in the Xbee. I have also tested that at this baudrate Xbee is sending the data properly in a normal scenario.
Now what I have done in my project:
I have registered my Xbee with the gateway and then it will go to sleep (I have used pin hibernate mode) then it will wake up by a digital pin of the Pro Mini. I have put a delay of 19ms, after which the Xbee will try to send data. After sending the data it will go back to sleep.
The problem is that it behaves randomly when sending data to the gateway (which also has the same Xbee series1). Sometimes it sends the data perfectly, sometimes sending fails. I have also enabled RR to retry 6 times in case the Xbee fails to send the data the first time.
I have no idea how to solve this problem because of the randomness in sending the data.
I have put two Xbees nearer (I have two nodes with the same hardware and the same code). There is an interval between of around 4 minutes. So when one Xbee sends the data perfectly, after that 4 minutes gae (time difference of two RTC on different nodes) the other one fails to send the data. In this condition what can I conclude?
As a side note, the Xbee will try to send the data every hour. To calculate that hour I have to use an RTC, which seems to work fine (I am sure because I have taken the logs, the RTC never fails to generate an interrupt).
So I am wondering what could be the possible reason and how can I fix this problem (without restarting anything if it is possible then nothing will be better than that).
And I have no choice to restart my controller.
How to debug this?
A few things. If possible, increase your baud rate so you spend less time sending data to/from the XBee. If you have a limited power budget, faster baud rates save time and energy. I don't know how the UARTs work on the Arduino, so I can't say whether 115,200bps is possible with a 1MHz CPU clock.
Second, make sure you wait for the XBee to assert CTS back to the Arduino after you wake it up. Never send to the XBee unless it's "clear to send".
Third, if you use API mode, you can watch for a "Transmit Status" frame from the local XBee back to the Arduino which will let you know when the module has successfully sent the frame, and it's safe for you to put it back to sleep.
We have a custom-built microcontroller card (ST32 / ARM Cortex M3) which has a camera attached. The camera captures 10-bit greyscale at 1280x1024 resolution. We need to send that image data back to a PC host over serial. That's quite a big chunk of data; at 115200 baud transfer would be 3 minutes, assuming everything goes fine. Anything I implement to ensure robustness would seem to slow that process down (eg split into blocks, checksum the blocks, ask for resend if corrupt). So was wondering how people might make a good compromise between speed and integrity.
We are currently seeing real transfer times of about 6 minutes. We had to set the UART baud rate at a weird value - 1036800 - because at 115200 there were issues (PC is running at 115200). I'm more software than hardware so any thoughts as to why that might happen would be helpful!
Start by doing some easy compression on your image.
Either run-length encoding or delta encoding will give you less data to send.
There are much better algorithms like TIFF but you may want to trade off the complexity of TIFF-ing your buffer for easier software on the embedded side.
Then you can afford something simple like Xmodem for your compressed data.
That has the useful property of being a standard protocol too.
That might lead you to using a terminal+xmodem transfer style interface to your host.
That would make debugging the interface pretty simple too.
Tim Williscroft's answer about compressing your data is a nice first step.
Now from the serial protocol side, the real transfer rate depends a lot on how you configure and implement your software both side. The baud rate is not the only thing to care about:
Are you using hardware flow control? If using hardware flow control, you will be able to significantly increase the baud rate (x10) without generating overrun errors.
From the STM32 are you using DMA, interrupts or even worth polling method to manage the data transmission? I don't know the exact STM32 reference you are using but on the STM32 I used, the UART transmission FIFO was limited to 1 byte. So you are merely obliged to use DMA if you have performance issues.
Still from the STM32 side, you can greatly improve performances taking care on the bus accesses (and possible conflicts arbitration) your application is doing.
Moreover on STM32, all clocks are configurable. Using an external high speed oscillator (if one available on board) may be a good way to improve performance over the internal RC oscillator. Also take care about internal bus clock configuration!
Now from the PC side, the performance may be impacted depending how your application bufferize & treat the received data.
The first thing to do is to look where the time is taken:
Observe your UART signal with a scope. As you said the transfer takes twice the theoretical time, you shouldn't see a continuous signal. Without hardware flow control it is the STM32 that takes time to output data. With hardware flow control, also look at the flow control signal to determinate which side causes the pauses (it may be both).
I'm building a clock. I want to set the clock by plugging an Ethernet cable into the clock. Most of the time the clock would not be plugged into the Internet.
I have an Arduino board and an Ethernet shield that can successfully connect to a time server and read the time (See the UdpNtpClient example file under Examples > Ethernet).
The problem is that to configure the Ethernet shield, the Ethernet.begin() call blocks for 60 sec if the shield is not connected to the Internet. I would like the clock to tell the time and periodically check to see if it has an Ethernet cable plugged in, and if so, make any corrections to the time. Most of the time this check is going to have a negative result, however, so I can't have the clock freeze for 60 sec each time.
Is it is possible to detect if the cable is connected in a quicker way than the Ethernet.begin() function? Is it possible to write a "multithreading" solution, where Ethernet.begin() is non-blocking?
Looking at the stock Ethernet library, it's not possible to prevent it from blocking.
I'm guessing you're using DHCP? This appears to be where the blocking comes from. Do you get the same problem when using a static IP address?
There's a number of blog posts available on Google covering this exact issue, including some forks of the Ethernet library that would allow you to do this in a non-blocking fashion.
In the DHCP.h header file you can find the class definition for a new DHCP connection.
Then you can see that there is a default timeout value of 60000ms.
(helpful hint: if you get past the initial effort, and start using eclipse to manage your adruino projects, its really great because you can just press F3 on a functions like Ethernet.begin and take a bit of a trip through the libraries to find these types of settings)
Its difficult to know how long the timeout should be. But a minute seems like a really long time. Of course you don't want to go to short.
I wouldn't go less than 15 seconds.
/David Cox