Continuous capture and data triggers

[Florian Geib]

I saw LabTool yesterday at the NXP booth at Embedded World fair in Nürnberg and have two questions:

Can you capture continuously for a couple of minutes and stream the caputed data to the PC or capture just as long until the internal memory is filled?

Can you trigger on evaluated protocol data? Like I'd like to trigger on a UART TX signal when it transmits 0xA0.

[Anders Lindvall]

Hi Florian,

>Can you capture continuously for a couple of minutes and stream the caputed data to the PC or capture just as long until the internal memory is filled?

No that is not possible at this time. All data is transferred after the capturing has completed. Implementing some sort of streaming of the data is possible but it requires considerations regarding what sample rates are supported so that the sending of the data doesn't impact the sampling.

> Can you trigger on evaluated protocol data? Like I'd like to trigger on a UART TX signal when it transmits 0xA0.

No that is not possible at this time. The reason is that the triggering mechanism is in the firmware and the signal interpreter is in the PC program. There are however a couple of ways that this could be implemented:

1) It should be possible to implement a software trigger for really low sample rates. That function could then search the sampled data for a specific pattern. 

2) The LPC4370's SGPIO block is used for sampling of digital signals. It has support for pattern matching which could possibly be used to locate your 0xA0. However there are problems with sample rates, data rates and the pattern matching that will make this option difficult to implement.

To sum it all up, unfortunately neither of the two features are available today. We had them on our wishlist when the product was being developed but some other features with higher priorities got included instead. The software is open source so perhaps the features will be added some day.

Best Regards,

Anders

--
You received this message because you are subscribed to the Google Groups "LabTool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labtool+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Florian Geib]

To sum it all up, unfortunately neither of the two features are available today.

Thanks for the detailed reply. Unfortunately these two points are important for me so I will keep LabTool in mind and check back later.

[Simon Ellwood]

I intend to add continuous sampling to Labtool in the coming months. What sampling rate do you need?

I will be using around 1 mega-sample per second, and will record to hard disk.

Once we have the continuous sampling then the decoding can be done on the PC and stopped some time after an event is detected with the time the event is generated marked as zero time, which will probably do what you want.

This will take me a while to get done however.

All the best.

Simon.

[Nathan McCorkle]

Simon, I thought the point of having labTool setup with the ADC to USB
through DMA was to enable high-speed streaming. Are you saying the
foundation is layed, you just never built the streaming functionality?
Is error-correction implemented already (i.e. if there is lots of USB
traffic, do packets get buffered on the hardware side, or if there is
a transmit error do packets get re-transmitted without losing other
data)?

> --
> You received this message because you are subscribed to the Google Groups
> "LabTool" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to labtool+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
-Nathan

[Simon Ellwood]

Hi Nathan,

I did not write LabTool and I have done no changes to the ARM side to date. The main application that brought me to LabTool is logging/ recording a lighting protocol called DALI. This is quite a slow protocol but I want to be able to record minutes or hours continuously to store and analyse on the PC.

I have started so far changing the PC side to add some basic DALI decoding capability.

The next major change in the streaming/ logging, recording.

I see no technical barriers at this time. I just need to find the time to modify both the ARM and PC side to add this functionality.

I know USB scopes like Pico already do something similar but LabTool is better for what I want by being open source.

As for the reliability of the USB transfer, this is indeed a risk with both USB bottlenecks/ reliability and general PC performance above the level of the USB stack. If needs be I will give the logger a dedicated USB port and not attempt other tasks on the PC during logging. I would hope that 1 Mega Sample however would not be a particular challenge for a modern PC.

I have done some study of the NXP chip and it looks like it should easily be able to do what I need.

My changes will be open source on my own github repository and I hope others will find the changes useful beyond my single DALI application.

To answer your question I have not actually started the modification needed to support continuous streaming yet so watch this space.

All the best.

Simon.

[Nathan McCorkle]

Ahh, ok. I guess I got you mixed up with Anders maybe, I think he was
one of (or the only?) the labTool developers.

> For more options, visit https://groups.google.com/d/optout.



--
-Nathan

[Anders Lindvall]

Hi,

To try to answer Nathans questions first:

> Simon, I thought the point of having labTool setup with the ADC to USB through DMA was to enable 

> high-speed streaming. Are you saying the foundation is layed, you just never built the streaming functionality?

LabTool is not using DMA to transfer from the ADC to USB. The DMA transfers from the ADC to a big circular buffer. That buffer is then sent over USB when the capture has completed (either forced end or when a trigger has been found). There is no streaming in the current implementation.

> Is error-correction implemented already (i.e. if there is lots of USB traffic, do packets get buffered 

> on the hardware side, or if there is a transmit error do packets get re-transmitted without losing other data)?

The USB bulk transfers that are used guarantees that the data arrives at the PC correctly (builtin CRC) and in order. There is some error handing in the PC application to discard incorrect packages if detected. As the data is only transferred after a completed capture has finished there is little other traffic to collide with.

Simons questions:

> As for the reliability of the USB transfer, this is indeed a risk with both USB bottlenecks/ reliability and general PC performance above 

> the level of the USB stack. If needs be I will give the logger a dedicated USB port and not attempt other tasks on the PC during logging. 

> I would hope that 1 Mega Sample however would not be a particular challenge for a modern PC.

I think the issue is not on the PC side, assuming a USB2 port is used. The issue is at what speed the LPC4370 can send data and if it can do it without compromising the sampling. At the very start of the LabTool development when we were contemplating whether to use Qt or not and what USB transfer stack to use we did some benchmarking of the transfer rate of bulk transfers. At that time we could not reach more than ca 8Mbit/s in transfer speeds. We discussed that with NXP and there has been a lot of updates to the lpcUSBlib and the drivers after that but we have not run any more benchmarks.

On a side note the LPCOpen project (http://www.lpcware.com/content/nxpfile/lpcopen-software-development-platform-lpc43xx-packages) for the LPC4357 (very similar to the LPC4370) has a bandwidth test that claims transfer rates of > 200Mbit/s so that could mean that very high transfer rates are possible.

For me the big issue is how to make sure that the data capture is not affected by the USB transfer. I believe that the best way is to use one of the M0 cores that are also present in the LPC4370. If the M0 is setup to handle all the USB stuff and to handle start/stop of captures then the M4 is free to do the capturing without the constant keep-alive stuff that the USB stack requires. The M4 could (as it is doing today) keep storing the samples in a circular buffer and the M0 would read from that buffer and send the data. As long as the M0 is consuming samples faster than the M4 can collect them this would allow infinite captures.

Regards,

Anders

___________________________________________________
Anders Lindvall, Senior Software Architect

Embedded Artists AB
Davidshallsgatan 16
SE-211 45 Malmo, SWEDEN

E-mail: Anders....@EmbeddedArtists.com
http://www.EmbeddedArtists.com
____________________________________________________
This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. 
If you believe this message has been sent to you in error, please notify 
the sender by replying to this transmission and delete the message 
without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any 
such corruption, interception, amendment, tampering or viruses or any
consequences thereof.

[Simon Ellwood]

That's along the lines I was thinking too. The chip seems to have dedicated RAM for the M0 processors too. I was looking how to implement a half full interrupt for the DMA. The data sheet is however not the easiest to read.

Cheers.

[Andrea Bettati]

Hi to you all, I know I'm a bit late, but this group seems to be actually the only one on the internet talking about the LPC4370. What an underrated chip.
I'm trying to do something very similar to what is discussed here, did someone succeed?

[Simon Ellwood]

Hi,

Sorry I stopped work on Labtool when they would not accept the improvements and new features I was developing on my fork.

You will see there has been little change in the last three years.

Good luck with your efforts, the chip is indeed a powerful one, if only the documents were as good as the chip!

Cheers.

Simon. (fordp2002)

[Andrea Bettati]

Hi Simon,
thanks for your reply. It's always sad listen aboput a dev quitiing is project, but I can well understand your choice.

the chip is indeed a powerful one, if only the documents were as good as the chip!

You did stole my words, I'm having A LOT of difficulties in using ADCHS+DMA+TIMERS and I'm searching for support, I tried:

• NXP Forum (no luck)
• ARM Connected Community (lots of extremely good programmers, but no one ever used this chip)
• NXP Pro Support (no luck, it is just for LPCXPresso IDE, no support for drivers)
  

... Today I'm writing to Embedded Artists. I'm searching support because I need to work on this chip, not doing hobby and therefore I'd pay for it.
Do you know if someone is offering this kind of support? Did the labtool project stop?

Thanks in advance.

All the best,
Andrea

[Malay Shah]

Hi Andrea,

I am working on a project where I am using ADCHS+DMA+Timer+USB transfer to PC (in my project Times is not used extensively) I may able to help !!! basically working on similar lines of the labtools code and reutilised some of the labtool code.

Now, I am planning to extend this project, where in I will have to acquire continuous Low-speed ADC data with ADCHS data. and I am stuck with a problem, not getting any help!!!
I guess on this chip it's easier to work with ADCHS compare to low-speed ADCs.

Regards,
--
Malay Shah
Electronics Design Engineer
Healthcare Technology Innovation Centre (HTIC), IIT Madras.
Email - ma...@htic.iitm.ac.in

On Sat, Mar 11, 2017 at 8:20 PM, Malay Shah <ma...@htic.iitm.ac.in> wrote:

Hi Andrea,

I am working on a project where I am using ADCHS+DMA+Timer+USB transfer to PC (in my project Times is not used extensively) I may able to help !!! basically working on similar lines of the labtools code and reutilised some of the labtool code.

Now, I am planning to extend this project, where in I will have to acquire continuous Low-speed ADC data with ADCHS data. and I am stuck with a problem, not getting any help!!!
I guess on this chip it's easier to work with ADCHS compare to low-speed ADCs.

Regards,
--
Malay Shah
Electronics Design Engineer
Healthcare Technology Innovation Centre (HTIC), IIT Madras.
Email - ma...@htic.iitm.ac.in

--

You received this message because you are subscribed to the Google Groups "LabTool" group.

To unsubscribe from this group and stop receiving emails from it, send an email to labtool+unsubscribe@googlegroups.com.

[Andrea Bettati]

Hi Malay, I'm so glad to hear about your work!
I don't know if we can help each other, but it would be great. Would you mind if I write to you a PM? Just to explain what I'm working on so that you can do the same.
Anyway, I have no experience with the simple ADC on LPC470, but I used the one on LPC43S37 thanks to LPCOpen drivers and it worked quite good. But I guess your project is complicated, so I imagine some troubles may arise.

Looking forward to her about you,

Andrea

To unsubscribe from this group and stop receiving emails from it, send an email to labtool+u...@googlegroups.com.