I have an intelligent sensor for measure robot axis movements, i would read valuesusing modbus for every single reading position (it read values every 100ms)
I try using pymodbus:
slave = ModbusSerialClient(port='/dev/ttyAMA4', parity=N, baudrate=9600, timeout=1)
slave.connect()
while True:
print(slave.read_input_registers(300013, 2, unit=10))
time.sleep(0.01)
The problem is, my script start and read the first values but in 5,6 seconds exit because too many request to devices (devices does not respond)
There is a method for call a modbus device and get values in "RealTime" for example every milliseconds without problem due to the hight volumes of continuosly calls?
So many thanks in advance
Your code reads values at about every 10ms rather than 100ms. Typo?
Since your purpose is to get values in "realtime", but how fast you can achieve mostly depends on the sensor, if you can find the specs from sensor datasheet, e.g. minimal polling interval, please code accordingly, otherwise, you can keep testing with different interval values until you are satisfied.
Related
There are several "hi-res" timestamping functions in ALSA:
snd_pcm_status_get_trigger_htstamp
snd_pcm_status_get_audio_htstamp
snd_pcm_status_get_driver_htstamp
snd_pcm_status_get_htstamp
I would like to understand what points in time the resulting functions represent.
My current understanding is that trigger_htstamp represents the time when stream was started/stopped/paused. snd_pcm_status_get_trigger_htstamp returns a constant value and when I add audio_htstamp to that value the result is very close to the current system time.
audio_htstamp seems to start from zero on my system and it is incremented by a value that is equal to the period size I use. Hence on my system it is a simple frame counter. If I understand ALSA correctly audio_htstamp can also work in different more accurate way depending on the system capabilities.
driver_htstamp I guess by the name is a timestamp generated by the audio driver.
Question 1: When is the timestamp driver_htstamp usually generated?
With htstamp I am really unsure where and when it is generated. I have a hunch that it may be related to DMA.
Question 2: Where is htstamp generated?
Question 3: When is htstamp generated?
Question 4: Is the assumption audio_htstamp < htstamp < driver_htstamp generally correct?
It seems like this with a little test program I wrote, but I want to verify my assumption.
I can not find this information in the ALSA documentation.
I just dug through the code for this stuff for my own purposes, so I figured I would share what I found.
The purpose of these timestamps is to allow you to determine subtle differences in the rate of different clocks; most importantly in this case the main system clock that Linux uses for general timekeeping compared with the different clock that determines the rate at which samples move in and out of the sound device. This can be very important for applications that need to keep audio from different hardware devices in sync, since the rates of different physical clocks are never exactly the same.
The technique used is sometimes called "cross-timestamping"; you capture timestamps from the clocks you want to compare as close to simultaneously as possible, and repeat this at regular intervals. There is usually some measurement error introduced, but some relatively simple filtering can get you a good characterization of the difference in the rate at which the clocks count.
The core PCM driver arranges to take a system clock timestamp as closely as possible to when an audio stream starts, and then it does a cross-timestamp between the system clock and audio clock (which can be measured in different ways) whenever it is asked to check the state of the hardware pointers for the DMA engine that moves samples around.
The default method of measuring the audio clock is via DMA hardware pointer comparsion. This isn't terribly precise, but over longer periods of time you can still get a good measure of the rate difference. At the start of snd_pcm_update_hw_ptr0, a system timestamp is captured; this will end up being htstamp. The DMA pointers are then checked, and if it's determined that they've moved since the last check, audio_htstamp is calculated based on the number of frames DMA has copied and the nominal frequency of the audio clock. Then, once all the DMA pointer update is done and right before snd_pcm_update_hw_ptr0 returns, another system timestamp is captured in driver_htstamp. This isn't meant to be used when you're using the DMA hw_ptr method of calculating the audio_htstamp though.
If you happen to have an audio device using the HDAudio driver, you can use an alternate and much more precise method of measuring the audio clock. It supplies an extra operation callback called get_time_info that is used instead of the default method of capturing the system and audio timestamps. It the HDAudio case, it takes a system timestamp for htstamp as close to possible to when it reads an interal counter driven by the same clock source as the audio clock; this forms the audio_htstamp. Afterwards, the same DMA hw_ptr bookkeeping is done, but the code that translates the pointer movement into time is skipped. The driver_htstamp is still taken right before the routine ends, though; this is "to let apps detect if the reference tstamp read by low-level hardware was provided with a delay" as the comment says in the code. This is because there's no guarantee that the get_time_info callback is going to take a new system timestamp; it may have previously recorded an audio timestamp along with a system timestamp as part of an interrupt handler. In this case, the timestamps you get might not match with the available frames and delay frames counts calculated by hw_ptr bookkeeping, but the driver_htstamp will let you know the closest system time to when those calculations were made.
In any case, the code is designed in both cases to capture htstamp and audio_htstamp as closely together as possible, and for htstamp - trigger_htstamp to represent the amount of system time that passed during the period measured by audio_htstamp of the audio clock. You mostly shouldn't need to use driver_htstamp, but I guess it might be used with the USB Audio driver, as I think it and HDAudio are the only ones that do anything special with these interfaces right now.
The documentation for this, although it doesn't contain all the details you might want to know, is part of the kernel documentation: http://lxr.free-electrons.com/source/Documentation/sound/alsa/timestamping.txt?v=4.9
I build a small game controller for the Z1.
I have a process reading values from a Joystick sensor. It works fine.
Then, I added a second process, reading the value of the battery sensor every 5 minutes. But it makes the Joystick stop working: the value does not update anymore!
I found a workaround: when I have to read the value of the battery, I deactivate the phidget_sensor, activate the battery_sensor, read the value and then deactivate the battery_sensor and reactivate the phidget_sensor.
But I would like to know why I can not have both sensors activated at the same time ?
Thanks
Comes from Here.
The ADC is the "analogue to digital converter", basically is the component that provides you the voltage signal levels of an analogue sensor, so then it can later be used to translate to a meaningful value.
What happens is the battery sensor driver and the phidget driver each when starts configures the ADC on its own, thus overwriting the ADC configuration.
The expected use of both of these components is actually how you are actually using: enable, measure, then disable. This way you ensure at all times the ADC is configured the way your application expects. If you want to have this done in a single operation then I'm afraid you will need to modify probably the phidget driver and include this.
I hope this is the answer you expected, as you are asking why does this happens.
I'm new in alsa sound programming. I'm developing an application to record the audio in to a wav file in c language. I did some research on net but still not very clear about many topics. Please help.
This is the configuration I'm setting.
access : SND_PCM_ACCESS_RW_INTERLEAVED
format: S16_LE
rate: 16000
channel: 1
I have few doubts:
I'm highly confused between the period size and period time settings.
What is the difference between snd_pcm_hw_params_set_period_time_near() and snd_pcm_hw_params_set_period_size_near(). Which API should be called for capture? Similarly there is snd_pcm_hw_params_set_buffer_time_near() and snd_pcm_hw_params_set_buffer_size_near(). How to decide between these two APIs?
How to decide the period size value? I believe the same value is used in snd_pcm_sw_params_set_avail_min() call.
What value should be used for number of frames to be read in snd_pcm_readi()?
What is the importance of snd_pcm_sw_params_set_avail_min() and snd_pcm_start_threshold() APIs? Is it a must to call those
I'm referring the arecord implementation and another example code for capture.
Thanks in advance.
The period time describes the same parameter as the period size. It might be useful if the rate is not yet known.
You get interrupts (i.e., the opportunity to get woken up if you're waiting for data) at the end of each period. If you know how much data you want to read each time, try to use that as period size.
Read as many frames as you want to process.
The avail_min parameter specifies how many frames must be available before an interrupt results in you application actually being waken up.
The start threshold specifies that the device starts automatically when you try to read that many frames.
I have a dual channel radio where I have two RX_DIGITIZER_CHANNELIZERs and two DDCS. My waveform allocates both channels. The waveform just takes the data from each channel and outputs it to two DataConverters. I am using the snapshot function to capture data. When I start to collect data at higher rates some of the packets get dropped. Is there a way to measure how long a call such as pushPacket takes? If I used the logging function, it would produce too much output to measure how long it takes.
#michael_sw can you plot the data coming from the device in the IDE instead of saving to disk?
How are you monitoring the packet drops?
Do you need to go through the data converter? If you have to it is possible to set a blocking flag in SRI in the downstream REDHAWK device (see chapter 15 in manual) to cause back pressure and block until data converter is done consuming the previous data. This only helps if the data converter is dropping packets.
In the IDE there is a port monitoring mode where you can actually tell when data is being dropped (right click on port and select port monitoring) by a component.
Another option in the data converter you could modify the code to watch the getPacket call for the inputQueueFlushed to be true.
I commonly use timestamping - make a call to one of the system clock functions and either log the time or print the time to the console. If you do this in the function that calls pushPacket and again in the pushPacket handler then you simply take the difference. If this produces too much data, you can simply use a counter and log it only every 1000 calls, etc. Or collect the data for a period of time in an array and log/print them after the component is shut down. Calls to the system clock does not effect performance much compared to CORBA calls.
I would like to know if it would be somehow possible to handle a Serial.println() on an Arduino uno without holding up the main program.
Basically, I'm using the arduino to charge a 400V capacitor and the main program is opening and closing the gate on a MOSFET transistor for 15 and 20 microseconds respectively. I also have a voltage divider connected to the capacitor which I use to measure the voltage on the capacitor when its being charged with the Arduino. I use analogRead() to get the raw value on the pin, multiply the value by the required ratio and try to print that value to the serial console at the end of each cycle. The problem is, though, that in order for the capacitor to charge quickly, the delays need to be very small (in the range of microseconds) and the serial print command takes much longer than that to execute and therefore holds up the entire program.
My question therefore is wherther it would somehow be possible to get the command to execute on something like a different "thread" without holding up the main cycle. Is the 8bit AVR capable of doing something like this?
Thanks
Arduino does not support multithreading, but there are a few libraries that allow you to do the equivalent:
Arduino Multi-Threading Library
ArduinoThread
For more information, you can also visit this question: Does Arduino support threading?
The basic Arduino serial print functions are blocking, They watch the TX Ready flag then load the next byte to transmit. This means if you send "Hello World" the print function will block for as long as it take to load the UART to send 10 characters at your selected baud rate.
One way to deal with this is using high baud rate so you don't wait long.
The better way is to use interrupt driven transmit. This way your string of data to send is buffered with each character sent when the UART can accept the character. The call to send data just loads the TX buffer, loads the first character into the UART to start the process then returns.
This bufferd approach will still block if you fill the TX buffer. The send method would have to wait to load more into the buffer. A good serial lib might give you an easy way to check the buffer status so you could implement your own extra buffering.
Here is a library that claims to be interrupt driven. I've not used it myself. Let us know if it works for you.
https://code.google.com/p/arduino-buffered-serial/
I found this post: Serial output is now interrupt driven. Serial.print() just stuffs the data in a buffer. Interrupts have to happen for that data to actually be shifted out. posted: Nov 11, 2012. I have found that to be true BUT if you try to print more then the internal serial buffer will hold it will lock up until the buffer is at least partially emptied.