Standalone cRIO‑9053 with NI‑9215 & NI‑9467 for UTC‑Timestamped Data Logging

[wsimpson0050]

Re: Standalone cRIO‑9053 with NI‑9215 & NI‑9467 for UTC‑Timestamped Data Logging - NI Community

I posted this question awhile back and had a horrible understanding of what I was doing I now have a little better understanding of what I am doing, thank you GerdW and Zyong. I currently have the FPGA doing what I want it to do except the timestamp is one sample behind. On the RT side I am trying to save 4 channels of data (sampling at 100Khz) to a TDMS file (i can change it depending on what you guys recommend), timestamp of first sample needs to align with PPS within nanosecond precision, I think I just have to add a frame in the middle of the lower part of my FPGA code that just waits for PPS to do that... On the RT side I do not need to stream data to or from my PC as this system will be headless. I would like to know what structure (while loops) I can get rid of on the RT side, and what else i need to do to make this system headless. 

P.S. if there is a way i can stream the data to a raspberry pi that would also be very cool instead of saving to a TDMS file.  

[wsimpson0050]

Hello all, I am currently working with the cRIO data logger with GPS synchronisation and timing - NI Community 

I am using the the cRIO-9053 with the NI-9215 ADC and the NI-9467 C-series modules. I haven removed all instances of the 9403 and 9263 in a 9118 backplane and a 9022 controller (I think). I able to get everything to run but I am getting no data. The attached photo shows, circled in red, where I believe the error is occurring but I am not completely sure. I would eventually like to put the 'Host Generic GPS Logger.VI' on a raspberry pi if possible.

Thanks, again.

[ZYOng]

Before debugging the host VI, did you run the RT VI and were you able to see the data on the RT side?

I would eventually like to put the 'Host Generic GPS Logger.VI' on a raspberry pi if possible.

You can program Raspberry Pi with LabVIEW LINX Toolbox, but it will be headless and without any GUI.

If you want the GUI, you can't use LabVIEW on Raspberry Pi as LabVIEW does not support ARM CPU.

The alternative would be a Windows NUC with x86 CPU.

[wsimpson0050]

Thank you ZYOng, I found the error. I accidently deleted the case structure that enqueued the data for AI Inputs on the Host VI. see attached photo. 

"You can program Raspberry Pi with LabVIEW LINX Toolbox, but it will be headless and without any GUI."

This will ultimately need to be the solution.

[wsimpson0050]

Another question, I am only sampling using the first two channels from the NI-9215. I have a signal source connected to Mod1/AI0 (Channel 0) and nothing connected to Mod1/AI1 (Channel 1). My question is, why does the data look like this? The real data is being plotted for the wrong channel (Channel 1). I am able to plot the TDMS file in MATLAB but I have to plot every other sample.

[wsimpson0050]

Additionally, if I incorporate all 4 channels, inject a 10Khz signal into Channel 0 and a 20Khz signal into Channel 1 and nothing in Channel 2 or 3, my output is as shown in the attached image. 

[GerdW]

Hi wsimpson,

---

@wsimpson0050 wrote:

Additionally, if I incorporate all 4 channels, inject a 10Khz signal into Channel 0 and a 20Khz signal into Channel 1 and nothing in Channel 2 or 3, my output is as shown in the attached image. 

---

I see two issues:

1. There's some ghosting as you use a MUX AI module. NI has documentation on "ghosting"…
2. There is a mis-ordering of the AI channels in your task (I guess): if you would provide a downconverted version of your code I would be able to verify my assumption. (I prefer LV2019.)

[wsimpson0050]

Thank you:

• I had to submit a Version Conversion form. It wants me to sign into FPGA Timekeeper.lvlib in order to save it as a previous version (Its an authorization request from NI).
• I also realized a mistake I made in the first test, my signal sources had extremely different voltage inputs into 9215 (might have been causing some "ghosting" issues due to different voltage swings), I fixed it so that channel 0 and Channel 1 are receiving a 1Vrms sine wave.
  • Channel 0 is now receiving a 10Khz sine wave
  • Channel 1 is now receiving a 20Khz sine wave 
  • *See image with graph, still not quite right, but I can see that it's trying to do the right thing*
  • 
• Until I receive the Version Conversion, here is the portion of code from the FPGA, RT, and HOST VI's where I believe problems might be happening.
  • FPGA 
  • RT
  • HOST

[wsimpson0050]

Quick update, I did the same test but looked at the plot through NI MAX and got the same results indicating that the problem is not with the code. I will now bust this ghosting issue (ghostbusting). 

[wsimpson0050]

Another update, I was using a QuantAsylum QA403 as my signal source. This was the reason for my incorrect measurements, nothing to do with the code or NI hardware. I will need to verify this later though.