DataV versus DataRaw question

[Karri Kaksonen]

Hello,

I am a bit puzzled about how to use the DataRaw Acquisition functions.

When I connect a square signal to channel A I get a square wave when I use the DataV function.
Data: 0.334961
Data: 0.440552
Data: 0.434082
Data: 0.431152
Data: 0.429932
Data: 0.429077
Data: 0.429077
Data: 0.378784
Data: -0.022461
Data: -0.009766
Data: -0.005127
Data: -0.003052
Data: -0.002319
Data: -0.001831
Data: -0.001709
Data: 0.218628
Data: 0.443115
Data: 0.434814
Data: 0.431274
Data: 0.429810
Data: 0.429443
Data: 0.429565
Data: 0.429565
Data: 0.042236
Data: -0.011719
Data: -0.005737
Data: -0.003296
Data: -0.002563
Data: -0.002075
Data: -0.001831
Data: 0.100952

The DataRaw function will just get noise
Data: 92
Data: 82
Data: 92
Data: 78
Data: 78
Data: 92
Data: 78
Data: 90
Data: 80
Data: 92
Data: 80
Data: 92
Data: 78
Data: 92
Data: 90
Data: 80
Data: 92
Data: 78
Data: 84
Data: 86
Data: 92
Data: 82
Data: 78
Data: 84
Data: 86
Data: 82
Data: 84
Data: 92
Data: 90
Data: 78
Data: 90

The code was run by redirecting the output to a file like
./run.sh 10.88.0.65 > file.dat

Am I missing something or is there something wrong with the function rp_AcqGetLatestDataRaw?

--
Karri

[Karri Kaksonen]

The expected result would have been like this:

Data: 7298
Data: 7146
Data: 7082
Data: 7054
Data: 7044
Data: 7038
Data: 7036
Data: 1568
Data: -212
Data: -102
Data: -56
Data: -36
Data: -30
Data: -24
Data: 746
Data: 7384
Data: 7174
Data: 7092
Data: 7060
Data: 7044
Data: 7038
Data: 7036
Data: 3472
Data: -260
Data: -124
Data: -64
Data: -42
Data: -30
Data: -26
Data: -24
Data: 6268

I can easily make if from the DataV output by

printf("Data: %d\n", (int)(buff * 16384));

This is a bit time consuming compared to getting the DataRaw to work.

--
Karri

[Kilroy]

Same issue here ...
Some strange result occur also when I change the signal only ...
Regards

[Nils Roos]

I don't have access to the librp.so source code, but I'll try to make somebody who does look into it.

[Nils Roos]

(Posts regarding librp licensing moved to Red Pitaya API announcement)

[Kilroy]

Thanks Nils to clear the status of the rplib.

Anyway still there exists some issues with the functions as well as the behaviour of these functions.

@Karri: have you expirienced strange behaviour when using the rp_AcqGetDataV function and you only changed the decimation (I prefer the term pre-scaler) to change the sample time?
I have some issues there as well. I changed the decimation from 64 to 1024 to extend the sampling time and the result expected was not met. Instead if that i only had noise like in rp_GetDataRaw function.

I am using the gnuplot program to visualise the results. Attached you will find to screen shots to make more clear what i mean.

Regards Uwe

[Karri Kaksonen]

I am actually using 1 and 8 as the real prescalers. The only real problem I had was to understand the external trigger.

Using rp_AcqSetTriggerDelay(0) put the trigger point in the middle of the sampling buffer. By trial and error I just tried rp_AcqSetTriggerDelay(array_size / 2). This moved the trigger to the start of the buffer. I wonder if this is the desired behaviour?

--
Karri

[Kilroy]

So that seems to be the behaviour like an oscilloscope. Good to know.
I used the "acquire" example from the SDK at my starting point to get the compilation working. Then modified the source code to use the "librp" because it was called RP Base library thinking that this is the base for all further programming. Seems to be a misunderstanding
Anyway, first steps worked well and so I went on.
I will attach current source file so you may have a look at it. Most parameters are settable via command line parameters.
With some slight modifications i got the other decimation factors working now. Seems I had to disable the trigger after the rp_Reset() function call. Then setting the trigger mode as the last command will work.
Kind of strange for me was the fact that I had to first use rp_AcqStart() before setting the trigger mode. Usually all settings should be done and after doing that the sampling process can be started.
Its good to have someone using the same lib and can communicate with.
Regards Uwe

[Karri Kaksonen]

Thanks for your code.

I am just trying to port an existing application to see if the quality of Red Pitaya is at the same level as dedicated digitizing cards. The card itself is so cute and small. It would open up our navigational aids in icy waters to much smaller vessels that don't have room for bulky equipment.

The question is how many samples can we send from the FPGA to a multicast packet within 500 usec. The sampling itself seems to work ok. But there may still be room for improvement in the FPGA to RAM transfers.

I wonder if it would be feasible to create a routine like

int rp_AcqGetDataPosRawDecimated ( rp_channel_t channel,
uint32_t start_pos,
uint32_t samples,
uint32_t step,
int16_t * buffer
)

Then I could fetch only the data I need from the FPGA. Like:
rp_AcqGetDataPosRawDecimated(RP_CH1, 0, 1024, 1, buf);
rp_AcqGetDataPosRawDecimated(RP_CH1, 1024, 1024, 2, buf+1024);
rp_AcqGetDataPosRawDecimated(RP_CH1, 1024+2*1024, 1024, 3, buf+2*1024);
rp_AcqGetDataPosRawDecimated(RP_CH1, 1024+2*1024+3*1024, 1024, 4, buf+3*1024);
rp_AcqGetDataPosRawDecimated(RP_CH1, 1024+2*1024+3*1024+4*1024, 1024, 5, buf+4*1024);

This would fetch 5120 samples from the FPGA instead of 16k. But as I don't have the sources I don't know if this could be implemented with the current design.
For radars it makes sense to lower the resolution when the range gets longer. With 131us you can see data up to 10NM or 30 mins of sailing.

--
Karri

[Kilroy]

I have researched a bit in the hardware documentation and it seems that the librp.so is a 1:1 implementation of the hardware functions.
So I will give it a try to to create a rp_AcqGetDataRaw() function by myself and see if the same problem with that function still occurs.
Unfortunately I am on an exhibition until next week Wednesday starting tomorrow. I am looking forward to get these things solved, because that little device is so versatile and so powerful with an unbeatable price that it would be a PITA to cancel that project.
Well .. your application looks totally different then ours. We have to record a single event triggered either external or at specific signal level. We will use usually one channel, but sometimes two. Event length will be approximately 10 ms and and the amplitude will be between 0 V and 10 V .
But I also need some additional signal from the GPIO.
If the source code of the library will not be released, then I am sure I will write my own lib using the same functions.
Regards Uwe