Author Topic: We made a portable USB scope for teaching our electronics design course!  (Read 18260 times)

0 Members and 1 Guest are viewing this topic.

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
Hey everyone!

We're big fans of EEVBlog, and one of our co-workers suggested we share our story with you guys. So here we go!

We teach an intro to electronics course at Northwestern University just outside Chicago, IL, and in this course we take students from not knowing what a breadboard is to being able to read datasheets and design their own circuits from scratch. It’s the first course in a sequence of three in our ME department that teaches kids about embedded computing and mechatronics design.

Our philosophy is teaching and learning by design. For that, a hands-on experience is crucial. But, in an academic lab setting, half or two-thirds of the class invariably sits back and lets the other members in the group do most of the work. We’ve all seen that. Our biggest challenge was to structure our curriculum so that every single student was forced to build their own circuits. You can only learn electronics if you do electronics.

Once laptops became ubiquitous, we realized we could use them as a screen to an oscilloscope, and instead have them build stuff in class, on their own. So, we started playing around with different devices.

We owned quite a few of these for a while, but they didn’t have a power supply, and cost $200 each. http://forums.parallax.com/attachment.php?attachmentid=104960&d=1384320228

We also had a lot of these, but they were also a bit expensive, like $400. http://www.mccdaq.com/images/photos_265/USB-1208FS_265.jpg

We just couldn’t find anything that fit exactly what we needed. Cheap enough that we could ask students to buy them outright, and capable enough to build basic circuits. Also, more and more of our students had Macbooks, and these things never worked on a Mac. So we built our own. It’s called nScope, and we just recently made it available to the public via Kickstarter.

http://www.nScope.org
http://www.kickstarter.com/projects/nscope/nscope-a-lab-for-every-laptop


But since this is an electronics blog, We wanted to talk about the electronics side of it.

We started out using a Microchip controller paired with an FTDI chip, (we use PIC controllers in our entire sequence). Turns out… FTDI is great if you have just your own computer… but installing their drivers smoothly on hundreds of other random computers is hard. So we changed it to HID. If a keyboard can work even in BIOS, we figured HID was a good choice for robustness. We’ve been really happy with that so far.

The other major issue was power supply robustness. No matter how many times you warn students about shorting +5 and GND… they’ll do just that. We had to build the power supply to be robust to a dead short. We implemented several different methods over the past few years, but we’ve settled on completely separating the 5V USB line from the external power line. We use buck-boost converters to create the +/- 5V lines, and we monitor the total power usage with a high-side current monitor. With our implementation, a short is detected and handled all without ever disrupting USB communication. We also use those +/-5V lines for signal conditioning, so we had to use surprisingly expensive capacitors to get the noise levels down… a lesson we won’t forget.

Other frustrating aspects of development include, but are not limited to:
  • Way more program memory than necessary, but very limited RAM on a chip
  • I2C in general
  • USB crashes not handled by an OS in any reasonable way (seriously… there have been days where the computer was hard reset 20-30 times…)
  • soldering 2x2mm QFN chips by hand
  • 16 bit ints in firmware… 32 bit ints in software…

Anyhow, if you made it this far, thanks for reading. Check us out if you’re interested!

http://www.nScope.org
http://www.kickstarter.com/projects/nscope/nscope-a-lab-for-every-laptop
« Last Edit: May 12, 2015, 03:57:36 am by nscope »
 

Offline charlespax

  • Regular Contributor
  • *
  • Posts: 191
  • Country: us
    • Pax Instruments
From our previous messaging on Kickstater you said,
Quote
The hardware, firmware, and software will not be open source. The API will provide total access over the hardware capabilities of nScope, and will be well documented with examples.

With your handy I/O I can see this in some automated production testing applications. Can you talk a bit about what hardware capabilities can be controlled and maybe some use cases you envision beyond education?

This looks like a wonderful project. I love small, quality tools like this. It would look great right next to my Saleae Logic. Best of luck to you  :-+

 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
Yeah, I can sure elaborate.  We didn't make it open source largely because it'd be more work for the user. We're designing nScopeAPI to offer complete control of the hardware. API users will be able to arbitrarily set outputs to any frequency, any voltage, and DC offset, any wave type. API users will be able to request input data to be read at any possible rate, any possible number of samples, and at any range of voltages.

If we simply released the source and no API, users would have to figure out what values to set to which registers in the firmware, and how to call the USB libraries to send the proper data structure to command the nScope correctly.  Our API handles all the low-level nitty gritty, and allows nScope users to control things in a much more workable space. After all, we use it for our junior/senior labs for data measurement and analysis... can't be too complicated.

Even we are impressed with our API capabilities.  Here's a link to our most impressive API demo yet.  In this video we demonstrate how the pulse outputs can be updated with the API at a 200Hz rate, while the inputs are read at the same 200Hz rate to implement a feedback PID controller.  This stuff is implemented in the API, not in the firmware, so from a users perspective, it's only about 20 lines of code, all running in a python shell.



One last thing... although our software won't be open source, we're writing it using just our API.  No feature in the software will use anything that is not completely accessible to everyone via nScopeAPI. In fact, just the opposite will happen.  Our software will not take full advantage of nScope's capabilities. Not even close.  It's why we're going to launch an online repository of python and matlab code for using nScope via the API.


 

Offline Esposch T. Tapir

  • Contributor
  • Posts: 30
  • Country: au
 :palm: :palm: :palm: :palm: :palm: :palm: :palm: :palm:
Are you serious?
This is almost the exact same product to what I've been working on over the past couple of months.
Hahaha.  Well, there goes my big idea.
Bachelor of Engineering (ECSE) with Honours.
Every time I write a line of code or build a circuit I am reminded that, in the grand scheme of things, I know bugger all.
 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
This is almost the exact same product to what I've been working on over the past couple of months.
Hahaha.  Well, there goes my big idea.

Well don't stop working on it! We've learned so much from doing this, and that's the best part.  Keep at it, maybe yours will end up way better than ours.  At the very least, you'll learn a huge amount about the hardware-firmware-software interface.

 

Offline Esposch T. Tapir

  • Contributor
  • Posts: 30
  • Country: au
Well don't stop working on it! We've learned so much from doing this, and that's the best part.  Keep at it, maybe yours will end up way better than ours.  At the very least, you'll learn a huge amount about the hardware-firmware-software interface.

Yeah, definitely.
Can't give up now - especially as I'm doing it as a project through my uni (semi-independently) and plan on graduating.  Besides, our two products are a little bit different.

Good luck with the Kickstarter, though.  Looks like a fantastic product and you've definitely had a fantastic idea!

Thanks for the support!
Bachelor of Engineering (ECSE) with Honours.
Every time I write a line of code or build a circuit I am reminded that, in the grand scheme of things, I know bugger all.
 

Offline abigbell

  • Contributor
  • Posts: 17
  • Country: 00
"4 Msps, 12-bit resolution, 4 channels "

how do you get that with pic24 ?
 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
"4 Msps, 12-bit resolution, 4 channels "

how do you get that with pic24 ?

With this:
http://ww1.microchip.com/downloads/en/DeviceDoc/30009312c.pdf

But... although it's specced at 10Msps... you can't actually do anything that fast unless you either underclock or overclock your chip.  And handling the data is so hard with the poor DMA design... shaking my head at Microchip sometimes..
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
The only screen shot that shows the function generator shows just 500Hz and it's close to the maximum slider value. At least you should be able to push it to what the scope could read back. Also the horizontal timing is just 100us per division so a signal that takes 2 divisions per period is what? just 5KHz?

You are already funded so its a moot point but the specs are vague since they don't show bandwidth or frequencies.


 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
The only screen shot that shows the function generator shows just 500Hz and it's close to the maximum slider value. At least you should be able to push it to what the scope could read back. Also the horizontal timing is just 100us per division so a signal that takes 2 divisions per period is what? just 5KHz?

You are already funded so its a moot point but the specs are vague since they don't show bandwidth or frequencies.

All of the screenshots and things are from last year's model.  We haven't finished developing this year's.  Our new function generators have much higher bandwidth, around 500kHz (but not fully specced, as it's not fully developed). Our pulse generators now go to the full 4 MHz. As for horizontal timing, last year's model is 10 times slower than this years.  Sorry for any confusion!

 

Offline ez24

  • Super Contributor
  • ***
  • Posts: 3082
  • Country: us
  • L.D.A.
Very interesting - thanks and I will follow carefully.

Also doing something similar but at a much less scale - just started on the PS and shorting problem and notification of it so an instructor can see that there is a problem from a distance.

YouTube and Website Electronic Resources ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline alank2

  • Super Contributor
  • ***
  • Posts: 2183
I *really* love breadboard addons and it looks like you've got the king of them here!

Here is my breadboard meter.  It is very basic compared to what you are doing, very basic.  It does voltage, current, low/avg/hi/relative.

http://home.earthlink.net/~alank2/bbmeter/bb1.jpg
http://home.earthlink.net/~alank2/bbmeter/bb2.jpg
http://home.earthlink.net/~alank2/bbmeter/bb3.jpg

After the kickstarter, how much will your product be to purchase?
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Product looks very nice. Seems to be on the expensive side but am not sure what's goes into it.

We didn't make it open source largely because it'd be more work for the user. We're designing nScopeAPI to offer complete control of the hardware.

Why not providing the API and releasing the source code 'as is'. If your goal is education, the hardware/software source files may be useful as well and will allow mixing and creative applications.

 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
Why not providing the API and releasing the source code 'as is'. If your goal is education, the hardware/software source files may be useful as well and will allow mixing and creative applications.

Releasing the firmware and low-level software will only serve to make support more difficult.  Multiple versions of things floating around online, people reading "as-is" then still asking for help... all headaches that aren't worth the benefit.

nScope wasn't built to have hackable firmware. None of the controller pins are broken out, and none of the pins are re-mappable. In fact, all of the inputs/outputs are first put through carefully designed signal conditioning circuits specific to nScopes purpose. The reason it's so expensive is the complex analog front-end. The two function generator outputs are SPI controlled DDS chips (to which we completely expose all functionality via the API) and then sent through variable gain amplifiers and variable level shifters (again, completely controllable via API). The four analog inputs are buffered and sent through independent variable gain amplifiers and variable level shifters (completely controllable via API). About the only thing you could do is... change how we send data to the computer (which we have carefully optimized).

Suppose we did release it. You would need to pick through our code and figure out where and how we're sending USB packets, what the data in those packets means, and how to interpret packets on the firmware and software side. And then you'd still be stuck with input and output pins that are hooked up to circuits that were specifically made for conditioning nScope's input and output. Anyone who has the ability and time to manage such an effort surely would know that starting from scratch with their own controller would be much faster to implement a custom solution.

Our goal is education, but a better platform for teaching firmware/software integration is a controller dev board.  We also made one of those, but it's not for sale as it's not really unique...

http://hades.mech.northwestern.edu/index.php/NU32:_Introduction_to_the_PIC32
« Last Edit: May 13, 2015, 04:30:26 pm by nscope »
 

Offline wblackledg

  • Regular Contributor
  • *
  • Posts: 187
  • Country: us
Start shorting Rigol stock..  :-DD

Any idea what price point you will sell these at?
 

Offline ez24

  • Super Contributor
  • ***
  • Posts: 3082
  • Country: us
  • L.D.A.
Start shorting Rigol stock..  :-DD

Any idea what price point you will sell these at?

$89 (within 13 days)  right ?

https://www.kickstarter.com/projects/nscope/nscope-a-lab-for-every-laptop
YouTube and Website Electronic Resources ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline tja

  • Contributor
  • Posts: 18
Releasing the firmware and low-level software will only serve to make support more difficult.  Multiple versions of things floating around online, people reading "as-is" then still asking for help... all headaches that aren't worth the benefit.

This looks like a great product, and I have backed it, but the above quote is just nonsense I am afraid. A million thousand devices have open sourced their firmware and don't have any problems - you simply state that only the official versions have any support, and ignore support requests for anything else.

Then, when the burst of activity delivering the initial batch has died down, and your thoughts are turning to software upgrades and bug fixing, you can have a loook at what the community has produced, and consider integrating that into the base product - you may be surprised!
 
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
If it's for students it should be open source, period. The curious ones should be able to browse the design files and see how you did it. I can see keeping it proprietary if you were a separate company, but you work for the school? Shame on you, everything you do should be educational.

The support complaints are bullshit, just don't support other versions. Provide them with the official software installed, and if you want support, you keep using it. But you're not doing your job as an educator if the full CAD, firmware, and PC source files aren't available.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Yeah, I can sure elaborate.  We didn't make it open source largely because it'd be more work for the user. We're designing nScopeAPI to offer complete control of the hardware. API users will be able to arbitrarily set outputs to any frequency, any voltage, and DC offset, any wave type. API users will be able to request input data to be read at any possible rate, any possible number of samples, and at any range of voltages.

If we simply released the source and no API...

:blah: So you think that there's a reason an open-source project can't have an API? Or that's what you hope we'll believe?
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
This looks like a great product, and I have backed it, but the above quote is just nonsense I am afraid. A million thousand devices have open sourced their firmware and don't have any problems - you simply state that only the official versions have any support, and ignore support requests for anything else.


First off, thanks for backing! Second, as a backer, would you personally like the source code? What would you do with it? Would you rather the source code for the firmware, the API, or the software? What would you do with each of these components (other than just see how it works)? I honestly believe that it would take you less time to build your own USB-scope than it would take to figure out how we implemented ours.

And to be honest, we're not totally opposed to open-sourcing the thing, but there's a few things to consider. First off, it can't actually be free software, since the firmware is compiled with a proprietary compiler, as is the Windows implementation, and the Matlab implementation. Second, we're not just going to post all the code online with no guidance whatsoever. That's reckless and dumb.  It invites people to steal it and completely rip us off, and it's honestly how 90% of open-source projects die.  Open-sourcing stuff takes effort, and we're not ready to put that effort in yet.  If 1000s of people own nScope, are engaged in an online community and are frustrated with the lack of customizability the API allows (and think, for some reason that the hardware is capable of more customizability), then yes, we'll take steps to open-source it.

But if you're dissatisfied that it's not open source just because you like things to be open-source for the sake of open-sourceness... then sorry.  We're only going to make it open source if there is a really compelling reason to. For now, an open API takes care of the need for customizability in a much more elegant way.
« Last Edit: May 27, 2015, 07:54:01 pm by nscope »
 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
If it's for students it should be open source, period. The curious ones should be able to browse the design files and see how you did it. I can see keeping it proprietary if you were a separate company, but you work for the school? Shame on you, everything you do should be educational.

That's a blanket statement that's completely unfair to us.  We are educators but actually own this material outside the university. We also teach a class on how to build things like nScope (microcontroller programming), but we teach from the ground up. We do not feel that providing a completed project to tear apart is an effective way to teach.

Releasing nScope's source to teach about microcontroller programming would be akin to teaching an operating systems class by giving everyone the linux kernel and saying "go learn".  People learn by building themselves, and to teach microcontroller programming, we made a different board, (a programming sandbox). If you're interested about that one, it's here. http://hades.mech.northwestern.edu/index.php/NU32:_Introduction_to_the_PIC32

At the end of our mechatronics sequence we teach all materials that allow students to build nScope, and if there is a student that is interested in how we built nScope, we absolutely tell them exactly how we do it. But to be honest, most if not all of them aren't interested in building nScope, they're interested in building their own stuff... cars, drones, simple medical devices... you name it.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
I didn't say to teach with it, I said to make it available for the more curious students who want to learn. As one of those students myself who has always wanted to see how things actually work, I'm quite tired of you people always trying to shove us down an educational assembly line and push us back on when we try to see what makes it move. Pay no attention to the man behind the curtain.... You're intentionally obscuring your educational materials, screw you. That's not education, it's business.

"We do not feel that providing a completed project to tear apart is an effective way to teach" is not a reason to hide the product, it's a reason not to build a lesson plan around it. Some of us learn outside the damn lesson plan.
« Last Edit: May 27, 2015, 09:10:21 pm by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
We really do not mean to intentionally obscure educational materials, and we certainly don't intend to hinder your learning. In fact, we're providing a whole host of electronics tutorials and hands-on labs on our website, so that when students and hobbyists get nScope, they can have a framework upon which to build their knowledge of electronics.

As for how nScope is implemented, well what would you like to know? It's actually pretty simple. A software stack creates a USB data packet that is formatted to request data at a certain rate, on a certain number of channels, and for a certain length. This formatted packet is sent to the PIC controller, which then interprets the packet and configures the ADC onboard (as per microchip instructions) with the requested settings to record the data. The data is stored locally in RAM and then packetized and sent back to the software stack via the USB line. The software stack unpacks the returned data and stores it in the appropriate data structure for user access. If you have any other questions, we'd be happy to answer them.

In fact, we'll go further.  If you end up backing, and get one of these in the fall, and then you've played around with the API and built some custom projects, but are still interested in learning more about exactly how we packetized the data, how we implemented the USB stack (hint, it's just Microchip sample code and an HIDAPI), then we'll show you how. It's really not anything secret, it's just years of meticulous attention to detail, and tedious design and integration of firmware and software.
 

Offline tja

  • Contributor
  • Posts: 18
... would you personally like the source code? What would you do with it? Would you rather the source code for the firmware, the API, or the software? What would you do with each of these components ...

I personally would do nothing with the code. I would simply monitor what the community is doing, and see if any developments appear that I am interested in, in which case I would consider upgrading. Much as I do with my Samsung phone, and cyanogenmod firmware.

The major risk to me as a punter buying this thing is that the company behind it disappears/loses interest once it has been released, and development stops. Releasing the code is some (minimal) insurance against this.

First off, it can't actually be free software, since the firmware is compiled with a proprietary compiler, as is the Windows implementation, and the Matlab implementation.

Then if the community really want to do anything with the code, it has to be ported to an open source toolchain. Been done hundreds of times before.

Second, we're not just going to post all the code online with no guidance whatsoever. That's reckless and dumb.  It invites people to steal it and completely rip us off, and it's honestly how 90% of open-source projects die.

I don't really have any great desire for you to open source the software, I just take issue with your justifications for not doing so, which, as eloquently described earlier in this thread are just bullshit.

It's your code - you  are free to do with it whatever you want. If you don't want to open source it you don't have to. No need to try and justify that decision.
 

Offline nscopeTopic starter

  • Contributor
  • Posts: 17
The major risk to me as a punter buying this thing is that the company behind it disappears/loses interest once it has been released, and development stops. Releasing the code is some (minimal) insurance against this.

We really appreciate this feedback, and we couldn't agree more. The way we see this, it could go two ways: 1. there's a lot of interest and lots more people want to buy it.  In that case we'll continue active support and keep closed source to ensure manufacturing and distribution is done on our terms, not somebody else's. or 2. there's not really enough interest to support any distribution. In that case we'll release the source so anyone who wants can build/buy/improve. Regardless, we'll keep using them in school for the next several years, as our need for nScope increases year after year.

And thanks for taking that risk on us. We sincerely hope you'll be satisfied with the job we're doing.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf