Gary Rubin

I don't know how applicable it is to FPGA, but using FIR filter was discussed here

Aside from the other things previously mentioned, have you tried reading a 6-element row from the big array, then reading the individual elements of that 6-element vector?  

It's been a while since I've played with this stuff, and I don't currently have LabVIEW installed on this machine, but I found that optimization was greatly aided by turning on the memory allocation dots.  You may find that your approach is making lots of copies of the big array.

Very nice!

My kids' elementary school has the district's only school-based MakerSpace program.  I volunteer teaching 3rd-6th graders to use Lego Mindstorms NXT.  With that giving them the background into graphical programming, this would be a great next step.

I really think you want to use a matched filter.  It's basically the cross-correlation that infinitenothing mentioned, and is very standard in radar signal processing to find the time of arrival of an echo even in the presence of noise and clutter.  You just need to have a copy of the signal that you originally sent out.  It can be implemented as a sliding point-by-point multiply in the time domain or in the frequency domain as a vector multiply (with some FFTs involved).  Some googling on Matched Filter should get you there pretty quickly.

Gary

Look into "matched filter"

If you think there's too much coupling between the actors, try switching to G-rated movies...   
<sorry, couldn't resist>

I agree with those proposing some form of RFID.  If you control the environment and can set up your readers wherever you want, I think that's the way to go.

I must be missing something - doesn't that only help you half the time?  What happens when i=2*usersize and both of your buffers have to roll over at the same time?  

If you knew your max resize, you could probably size them so that both the smaller and larger buffer aren't integer multiples in length and are unlikely to wrap-around within the same read block size.

Okay, I was missing something.  For some reason, I thought the idea proposed was 2 buffers so that one wraps around when the other doesn't.  I see that's not what SDietrich was suggesting, but I still don't see how his extra-long buffer keeps a wrap-around from happening.  I guess I'm still missing something.

one way to avoid rotating the buffer and still be able to use the Array Subset Node is the following:

• allocate a buffer twice the size the user requested
• apply writes to buffer also to buffer[usersize + i]
• use Array Subset Node to return any contiguous part of the buffer very efficiently as a contiguous subarray

 

I must be missing something - doesn't that only help you half the time?  What happens when i=2*usersize and both of your buffers have to roll over at the same time?  

If you knew your max resize, you could probably size them so that both the smaller and larger buffer aren't integer multiples in length and are unlikely to wrap-around within the same read block size.

If I stare at that picture with my eyes slightly crossed, should I expect to see a horse or something?

I was hoping for that too.  When I looked at this about 5 years ago, it was just memory access (peaks and pokes) to the CUDA-compatible GPU card.

At this point (and this may change), I'm looking at LINX as  just a set of driver functions, much like a dll.  I don't really care what's going on in the middle - all I know is that I make a function call and get the proper response.  

If I get to the point that I'm writing code to run on the Arduino and using LINX to talk to that code, my opinion may change.  Right now, I'm more than happy thinking of it as a black box.

EDIT: I've used plenty of non-NI acquisition hardware for which I've written LabVIEW wrappers around the vendor's dll functions.   I see the Arduino/LINX combination the same as those hardware/dll combinations.  That may be why you and I see this differently - I'm used to having black box functions sitting between me and the hardware, so I didn't even look into the LINX VIs.

Along the same line of thought, why should source code need to be well documented, it will just go into an EXE where the user doesn't see it anyway.

From a user standpoint, it doesn't.

If user experience isn't affected, do you care if MS Word source code is well documented?  Or even well-written? 

Unless you need to modify or support code, I don't see why in-code documentation matters.

So far LINX works and at this point, that's really all I care about from my middleware.

If I start trying to make it do things that outside its current scope, then I might care about the LINX VI architecture and design.  But isn't the whole reason for downloading such a library is so that I don't have to worry about such things?.

Except that when you follow the link from Dave's post you get to a page which looks like the card he is talking about and in red letter New Product! afterwards. After about 8 years it would seem a little strange to still claim it's a new product. CPCI isn't as quick paced as general computer technology but that slow!!!!???

Yes, I know.  One board that I was looking at says "Coming Soon", although it's been discontinued and replaced by a next generation.

That's why I was hoping for some first-hand experience that might indicate whether their hardware/software is better than their web presence.

I've downloaded the LINX LabVIEW interface for Ardiuno and am now doing my first LabVIEW programming after about 5 years of exclusively coding in MATLAB.

Wow, is it ugly!  And how did all those sequence structures get in there?! 

EDIT: I'm talking about my own code, of course.  The LINX VIs look just fine.

Talk about resurrecting and old post!

I'm also wondering about anyone's experience with General Standards boards.

Since they're still around 8 years after JDave's original post, they must be doing something right, but I'd appreciate some first-hand feedback.

JDave, did you end up buying that card?

Thanks,

Gary

I don't have LabVIEW installed on this machine and I may be confusing LabVIEW and MATLAB primatives, but I've seen a pretty fast approach that relies on a cumulative summation.  Textually, the algorithm is:

B=CumulativeSum(A)

SlidingAverage(i)=(B(i+windowsize)-B(i))/windowsize

Adjust indices as necessary to center your window in the right place and be careful with the edge conditions.

I'm more interested in the programming than the electronics aspect.

For that reason, I'd rather get buy some sensors/shields than sit there with my Horowitz & Hill on my lap.

Maybe once I get something going, I can try some circuitry.

Regarding LIFA, I just saw this little disclaimer:

Note: The Arduino microcontroller must be connected to the computer with LabVIEW through a USB, serial, Bluetooth, or XBee link. This toolkit does not provide for headless operation. 

Does this mean that the LIFA toolkit just supports the Arduino as an I/O device for code running on the PC?  I was hoping for something that would actually run on the Arduino microcontroller.

I'm not sure if this is the right sub-forum, but is anyone playing with this?

https://www.sparkfun.com/products/11225

I'd like to get a cheap copy of LabVIEW at home that isn't tied to work licenses.  The application would be playing around with my kids.

Ok Chris, I got the hint and "liked" your reply. 

Just logged on again for the first time in several years and the post leader board looks pretty much like it did when I was last active.  Is LAVA still growing?

I just kudoed it.

That's a capability I use all the time in Matlab.

So I can make all my bugs go away by simply describing the behavior in mydocumentation? Awesome!