I've got my Rasp with the latest firmware update and I´m doing SoC temperature reads every 5minutes (300seconds). I came across several temperature spikes ( from 50º to 70º and sometimes to down to 30ºC). These temperature spikes happen 2-3 sometimes 4 times everyday.
I've read there are some readout glitches on the temperature sensor, yet can this be a hardware malfunction? Maybey a software update (linux) will solve the problem?
I'm currently using it as a small homeserver, but if temperature spikes persist I'd probably have to get a passive cooler.
I'm also sure that during those upper spikes the workload of cpu/IO/gpu is kept the same.
It´s not exactly a solution but it solved my problem. I changed the SD card (8gb generic class 4) to a micro-sd adapter+sandisk 16gb class 10, installed the same raspbian (in fact the same image file!), also did the system updates and after 24hours running didn't noticed any spikes.
Maybee an SD card write/problem?
The sd card wasn't full by the way.
Related
I am using a G0 with one ADC and 8 channels. Works fine. I use 4 channels. One is temperature that is measured constantly and I am interested in the value every 60s. Another one is almost the opposite: it is measuring sound waves for a couple a minutes per day and I need those samples at 10kHz.
I solved this by letting all 4 channels sample at 10kHz and have the four readings moved to memory by DMA (array of length 4 with 1 measurement each). Every 60s I take the temperature and when I need the audio, I retrieve the audio values.
If I had two ADC's, I would start the temperature ADC reading for 1 conversion every 60s. Non-stop. And I would only start the audio ADC for the the couple of minutes a day that it is needed. But with the one ADC solution, it seems simple to let all conversions run at this high speed continuously and that raised my question: Is there any true downside in having 40.000 conversions per second, 24 hours per day? If not, the code is simple. I just have the most recent values in memory all the time. But maybe I ruin the chip? I use too much energy I know. But there is plenty of it in this case.
You aren't going to "wear it out" by running it when you don't need to.
The main problems are wasting power and RAM.
If you have enough of these, then the lesser problems are:
The wasted power will become heat, this may upset your temperature measurements (this is a very small amount though).
Having the DMA running will increase your interrupt latency and maybe also slow down the processor slightly, if it encounters bus contention (this only matters if you are close to capacity in these regards).
Having it running all the time may also have the advantage of more stable readings, not being perturbed turning things on and off.
I have four DS18B20 temperature sensors connected to my Raspberry Pi. I use 1wire and a pull-up resistor.
I read the values directly via cat from the 1wire devices and put the velues without calculation into a gnuplot data file.
The setup has been running fine for weeks now, measuring a coolbox at different places in a range between about 0°C and 30°C. I got quite accurate readings and plots.
But suddenly the values of all sensors start to "flutter", the became unstable. They also dropped -- all four -- about quarter of a °C. The flutter is about about 0.1°C to 0.2°C. Two of the sensors are actually inside fluid (0.5l and 25l) and thus it is virtually impossible that they suddenly drop or flutter.
The time of the event coincides with me checking the cooler box. I might have shifted or touched some sensoring parts. But can that explain the temperature shift? What happend? How can I fix it?
It seems that a cause of the problem could be resolution being lowered. This is a (volatile) setting stored in the sensor itself. It can be set to 9, 10, 11 or 12 bits. The higher the resolution the more precise the measurements will be, but at a cost of longer measurement time.
According to DS18B20 datasheet, by default the resolution is set to 12 bits after power up. In addition, the drivers handling 1-wire communication with the sensor often also by default set highest possible resolution during startup. This could explain why rebooting fixed the problem in case of OP, but doesn't explain why the change in resolution happened in the first place. That likely depends on the specific setup and will likely have to be resolved on a case-by-case basis.
Furthermore - to confirm that the measurements are indeed done at lower resolution, one can get the numeric values of the samples and check the minimum value by which the measurements change. For example, for 12bit resolution the minimum delta is 0.0625 degrees, while for 9bit resolution it may only change by 0.5 degree and nothing in between.
I am using a RSPI Zero W to record videos using motion detection. I have read others doing this easily with frame rates of 5 per second and above. I am only trying to get 2 frames per second.
Everything works fine, except the videos recorded do not keep up with real time. I still get 2 frames per second, but many of the frames are duplicates.
It seems that the PI0W can not keep up with it, but the CPU usage never gets much higher than 50%. Using a Class 10 SD card so I do not think it is a disk I/O problem.
I originally did this on a PI2B with no problems in 720p. I tried reducing the resolution to 640x480 and get the same result.
Any suggestions?
Setup:
Raspberry Pi Zero W
Raspbian 9.4 stretch
Apache/2.4.25 (Raspbian)
PHP 7.0.27-0+deb9u1
Samba Version 4.5.12-Debian
Motion 4.0 (installed via apt-get)
motion.conf
https://pastebin.com/Mr438ned
Example Video: Watch the timestamp. It should be updating every second
I have a project that consisted of transmitting data wirelessly from 15 tractors to a station, the maximum distance between tractor and station is 13 miles. I used a raspberry pi 3 to collect data from tractors. with some research I found that there is no wifi or GSM coverage so the only solution is to use RF communication using VHF. so is that possible with raspberry pi or I must add a modem? if yes, what is the criterion for choosing a modem? and please if you have any other information tell me?
and thank you for your time.
I had a similar issue but possibly a little more complex. I needed to cover a maximum distance of 22 kilometres and I wanted to monitor over 100 resources ranging from breeding stock to fences and gates etc. I too had no GSM access plus no direct line of sight access as the area is hilly and the breeders like the deep valleys. The solution I used was to make my own radio network using cheap radio repeaters. Everything was battery operated and was driven by the receivers powering up the transmitters. This means that the units consume only 40 micro amps on standby and when the transmitters transmit, in my case they consume around 100 to 200 milliamps.
In the house I have a little program that transmits a poll to the receivers every so often and waits for the units to reply. This gives me a big advantage because I can, via the repeater trail (as each repeater, the signal goes through, adds its code to the returning message) actually determine were my stock are.
Now for the big issue, how long do the batteries last? Well each unit has a 18650 battery. For the fence and gate controls this is charged by a small 5 volt solar panel and after 2 years running time I have not changed any of them. For the cattle units the length of time between charges depends solely on how often you poll the units (note each unit has its own code) with one exception (a bull who wants to roam and is a real escape artist) I only poll them once or twice a day and I swap the battery every two weeks.
The frequency I use is 433Mhz and the radio transmitters and receivers are very cheap ( less then 10 cents a pair if you by them in Australia) with a very small Attiny (I think) arduino per unit (around 30 cents each) and a length on wire (34.6cm long as an aerial) for the cattle and 69.2cm for the repeaters. Note these calculations are based on the frequency used i.e. 433Mhz.
As I had to install lots of the repeaters I contacted an organisation in China (sorry they no longer exist) and they created a tiny waterproof and rugged capsule that contained everything, while also improving on the design (range wise while reducing power) at a cost of $220 for 100 units not including batterys. I bought one lot as a test and now between myself and my neighbours we bought another 2000 units for only $2750.
In my case this was paid for in less then three months when during calving season I knew exactly were they were calving and was on site to assist. The first time I used it we saved a mother who was having a real issue.
To end this long message I am not an expert but I had an idea and hired people who were and the repeater approach certainly works over long distances and large areas (42 square kilometres).
Following on from the comments above, I'm not sure where you are located but spectrum around the 400mhz range is licensed in many countries so it would be worth checking exactly what you can use.
If this is your target then this is UHF rather than VHF so if you search for 'Raspberry PI UHF shield' or 'Raspberry PI UHF module' you will find some examples of cheap hardware you can add to your raspberry pi to support communication over these frequencies. Most of the results should include some software examples also.
There are also articles on using the pins on the PI to transmit directly by modulating the voltage them - this is almost certainly going to interfere with other communications so I doubt it would meet your needs.
I'm trying to extract data from 3.5" floppy disks formatted on a +D interface for a ZX spectrum. It's close but not exactly the same as for a PC. I've written software to do this in the past useing the BIOS to access a floppy.
However some disks are old and have bad sectors. I am trying to create a floppy drive controller to read a disk at a bit level to recover as much data as possible. I'm fully aware of how difficult this might be. I have however written a disk utility program that interfaced with the interface at a machine code level on the original spectrum computer, written in Z80 assembly software to emulate MSDOS to access and write files to FAT12 floppy disks. The original computer that accessed these disks did so using a 3.4MHz processor, so the Rasperry Pi that I'm thinking of using should be more than fast enough. I might even be able to run it from Linux but if not I have figured out to access the GPIO port, screen, keyboard and SD card using assembly language that would not need any kernal to run it. I've read up on how floppy drive reads and write data and have seen some basic example of how to opperate the floppy disk (not just the stepping motor).
I've done some research but have a few questions I can't seem to find answers to, and wonder if people here might know.
1) The read data pin (30). Does this return a logic high/low value of what's under the read head (rounding up or down to logic high or low), or is it analog? I ask because if it's analog, getting any input back would enable me to better try and recover corrupt sectors,but would make interface circuit harder to make, and depending on ADC used make interface with GPIO harder, and slower.
2) I know the molex power of +5V and +12V. But what current would a floppy expect?
3) I assume that the control pins from the ribbon cable on the floppy work at 0 or +5V, but that people seem to be able to run them at +3.3V. Does anyone know what they should be running at, and what their current tolerance are: what voltage and current the inputs expect, and what current/voltage the outputs deliver?
Many thanks for any information/knowledge that you might have on this.
A little late, but if someone else is interested:
1) The data output of the floppy is open-collector. So you can pull it up to your 3.3 Volts and will be fine.
2) 600 mA # 12V, 500 mA # 5V should be safe
3) Think of TTL input, that expects 2.4 Volts for HIGH. (2.5V according to the NEC 3.5" floppy drive).