Future Idea: Pushing DAQ usage

[drtrigon]

This is nothing I need, but something that came to my mind and wanted to bring up.

Currently the labrador is a very nice development tool/electronics lab - now how about also making it a very nice measurement and DAQ tool too? From what I can see adding a multiplexer (using the digital outputs for addressing) allows every user to enhance the labrador easily to say 16 channels. So for about 30$ we have a DAQ comparable to the ones from the big players (NI, etc. but also labjack, redpitaya, eg.) for the price of an Arduino. What is missing are drivers - software to access labrador functions, so I think of a simple command-line tool for use in scripts (bash, sh, batch, etc.) and a C/C++ lib for access from programming languages (https://github.com/EspoTek/Labrador/issues/31).

That would kind of bring professional grade DAQ to the "Arduino world" - roughly one order of magnitude lower priced. What do you think?

[EspoTek]

That's a really smart idea. Good news is that I've already started work on an API. Which will be provided in C++ lib and mex form.

I've got one more day of my PhD, then I can resume work.

Better yet, the last few weeks of my PhD involved writing an API for a different device (neurosignal amplifier) and I've learned a lot about MATLAB compatibility and shared Lib stability and building. Basically, I managed to solve a lot of the problems that I was struggling with before!

Give us a week or so...

[drtrigon]

Another point here is; if the device would be a bit more fool-prove and the software a bit more intuitive to use (e.g. "beginner" mode) we could use it in schools for education (for teenagers, ~14yrs). Again all concurring products are about 10 times the price of a labrador. At least I would be immediately willing of ordering 10 to 20 devices for one school I am working at. :)

[JennyEverywhere]

I love the idea of Labrador -- enough to have bought several -- but right now, my machines aren't behaving well with it. I STILL can't get my phone to work with it in OTG mode -- I don't think my phone does OTG correctly in the first place, and doesn't talk to serial devices in that mode, and my Linux boxen have goofball contentions in the serial driver stack, preventing it from working 99% of the time. I'm hoping 18.04, once I can upgrade to it, will work right. If not, I'll have to downlevel back to 14.04, since that's the version it last worked properly on. I really don't want to go downlevel like that, as the upgrades fixed problems in other areas.

It isn't just Labrador that this serial port crap has affected. It's breaking my use of my Digilent Analog Discovery 2 oscilloscope, too. Their support crew couldn't find a good solution for it either. I'm hoping that, eventually, this driver nonsense gets fixed and these devices start working for me more reliably. This is part of the reason why such devices are having trouble being adopted. They get unfairly blamed for the failure, instead of the host machine having a more fundamental problem. Windows, for as stupid as its port management is, works better in that regard than other operating systems or hardware integrations. I can use Labrador or my Digilent just fine on Windows...but I don't have a Windows box on my workbench. THAT machine runs Linux. So does my Chromebook, through Crouton, which is also on my workbench. I'd probably have trouble with it working on my Raspberry Pi...which also runs Linux. Come to think of it, my Android phone, with the bad OTG handling, ALSO uses a Linux kernel.

The system under Linux for the rules that control the devices...the name escapes me, and I have NOT mastered it, and don't have a clue how to write the rules for it...is a convoluted mess that I've tried to study, but don't understand. If someone could come up with a ruleset for the Labrador to handle the port management under 16.04 or 18.04 Linux, I'd love to pick their brains.

On Fri, May 18, 2018 at 4:05 AM, drtrigon notifications@github.com wrote:

Another point here is; if the device would be a bit more fool-prove and the software a bit more intuitive to use (e.g. "beginner" mode) we could use it in schools for education (for teenagers, ~14yrs). Again all concurring products are about 10 times the price of a labrador. At least I would be immediately willing of ordering 10 to 20 devices for one school I am working at. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EspoTek/Labrador/issues/37#issuecomment-390128974, or mute the thread https://github.com/notifications/unsubscribe-auth/ARoafWm3MPzC5jGVLukrk0WIs8I6Dstvks5tzoDJgaJpZM4SOKzu .

--

-+-+-+-+- Jenny Everywhere's Infinite: Quark Time http://quarktime.net

[EspoTek]

Drtigon, the hardware is actually designed to be foolproof. You can short any pin to any other pin and guarantee no damage. It's also difficult to break with external sources. You can hook up 18V directly to the signal generator, for example, and the only thing that will burn is one of "fuse" resistors which can be easily replaced with a blob of solder. Even if you can't solder, only the one output you damaged will become faulty; the rest will work OK.

Not really sure what I could do to make the software easier to use, but open to suggestions (please create a separate issue though)!

Send me an email at admin@espotek.com and I can get you a good deal on a class set, especially if you're happy to share educational materials you make. :)

[EspoTek]

Gwen, turns out there's a critical bug in the Android version of Labrador that only affects Windows users.

I'll explain it as best I can: There are two separate versions of the device firmware: 0x01 and 0x02. 0x01 is used on Windows x64 only, 0x02 is used on all other systems. They're almost identical, but 0x01 uses 6 separate endpoint buffers of 128 bytes (ie 768 bytes total) per USB frame, and 0x02 uses a single 1023 byte buffer. This is because the functions for synchronising separate endpoints are not present in libusb, but they are in the 64-bit version of libusbK (Windows-only version of libusb). Essentially, you can transmit all the data that Labrador needs on Windows x64 without having to reserve bandwidth that could be used by other devices, such as keyboards and mice.

In order to handle the two separate types of firmware, it has some code to detect what version the board is running.
When you connect the device to a Windows x64 PC, the Labrador software will check that it's running 0x01, and if you connect it to any other system (including Android) it'll check that it's running 0x02. If the expected firmware variant matches the version currently on the board, it does nothing. Otherwise, it'll flash the compatible firmware.

So, if you have a board that was last used on Windows, then plug it into an Android device, it'll try and re-flash the firmware. This usually isn't a problem, but it turned out that Android did not like this solution.

Essentially, due to Android's permissions ~hell~ system, I cannot directly call fopen() on a file bundled as an "asset" in the .apk. The quick-and-dirty workaround is to create a temporary copy of it on in the app's "data" folder, then call fopen() on that. Which is what I did. Unfortunately it turns out there's a bug in the version of Qt I used to compile the latest version. https://forum.qt.io/topic/85460/qt-5-10-0-rc-qfile-copy-on-android-not-works/10

This meant that the copy would always fail, so when it was time to write the new firmware to the device, nothing existed. So it wrote nothing. To make matters worse, I also had bad error checking. It would always erase the board's firmware, then attempt to write a new one. If the file wasn't present, it would still erase but not write any new firmware. Meaning you were left with a brick until you ran firmware recovery from the desktop.

A fix should be out for this in a few hours.

[EspoTek]

Gwen (again), I think you're referring to udev. There is a script bundled with the deb that handles the udev rules automatically. If you're on Ubuntu 16.04 LTS, this link here should do the trick: https://github.com/EspoTek/Labrador/releases/download/1.1/Linux_x64.tar.gz Just make sure to extract the whole tarball and install it by running the labradeb-install script.

If the device is not coming up, it could be a bandwidth issue. Try and remove other USB devices and reinsert it until it works. If that fails, go into firmware recovery and follow the prompts.

You can double check using the lsusb command. It should come up as device 03EB:BA94, Atmel Device.

You may need to enable isochronous USB in your BIOS too. A few boards allow you to turn it off for some strange reason.

[JennyEverywhere]

It's still not working under Linux. I used the install in the tarball you just linked. I can get it connected now, but it fails in calibration saying that the "values are out of range" and they have to be near 0v. I've got a pair of REALLY SHORT wires with Dupont pins on one end and an alligator clip on the other. When it asks to short channels 1 and 2 to the shield on the USB connector, I use that to do it. I STILL get the failure message and nothing works. I've tried DC and AC pins for channels 1 and 2.

Now, here's a question: The machine I'm on is somewhat old, and does NOT have USB 3.0. It's only 2.0. But your microUSB connector on the board is a USB 2.0 connector -- mini usb 3 is a different, wider connector, looking almost like an HDMI connector. So how can connecting it to a USB 3 or ESATA port (neither of which this machine has) work, when the other end of the cable is just a standard micro USB 2.0? Your troubleshooting page says to try that. I did on my Windows machine and it works, but it doesn't work on this USB 2.0 machine AT ALL. Ideas, or am I S. O. L.?

On Sat, May 19, 2018 at 1:06 AM, Chris Esposito notifications@github.com wrote:

Gwen (again), I think you're referring to udev. There is a script bundled with the deb that handles the udev rules automatically. If you're on Ubuntu 16.04 LTS, this link here should do the trick: https://github.com/EspoTek/Labrador/releases/download/1.1/Linux_x64.tar.gz Just make sure to extract the whole tarball and install it by running the labradeb-install script.

If the device is not coming up, it could be a bandwidth issue. Try and remove other USB devices and reinsert it until it works. If that fails, go into firmware recovery and follow the prompts.

You can double check using the lsusb command. It should come up as device 03EB:BA94, Atmel Device.

You may need to enable isochronous USB in your BIOS too. A few boards allow you to turn it off for some strange reason.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/EspoTek/Labrador/issues/37#issuecomment-390379635, or mute the thread https://github.com/notifications/unsubscribe-auth/ARoafUJLcEaN_DvBulkMjAv-vJ9pAx9jks5tz6hMgaJpZM4SOKzu .

--

-+-+-+-+- Jenny Everywhere's Infinite: Quark Time http://quarktime.net

[EspoTek]

If it loads, that's a good sign.

I can't really explain why the calibration process is failing without being there personally, though, or at least seeing some screenshots that show the voltage waveform at the start of the calibration step.

One alternative could be to short one of the Oscilloscope CH1 DC (Duplicate) pins to CH2 DC, and the other to Power Supply GND. That should short everything to GND and get you through step 2. https://github.com/EspoTek/Labrador/wiki/Pinout Other alternative is to copy your settings.ini from the windows build. Should be somewhere in AppData/EspoTek. Or just leave it. Calibration isn't necessary; just nice.

You're correct in saying that it uses a USB2.0 connector. It actually runs at USB1.0 speeds (12 Mb/s). There should be no advantage at all to using USB3.0 over USB2.0. I use a 2.0 port for my Labrador and have no issues. The reason the guide talks about USB3.0 vs USB2.0 ports is because they're typically driven by different USB controllers. Putting your Labrador on a different controller to your Keyboard/Mouse/Webcam can prevent them competing with one another for bandwidth (and the Labrador requests near-100% bandwidth on some USB controllers that slow down the clock to handle 12Mbps devices) - but it doesn't matter whether the Labrador is on 3.0 and the others are on 2.0, or vice-versa. At least, it shouldn't.

[JennyEverywhere]

There is no voltage waveform at the start of the calibration step. The waveform screen is EMPTY. It's not showing ANY waveform whatsoever. It shows nothing before the step and nothing AFTER the step. I hooked up my external signal generator and it does not display.

I'll keep playing with it and see what I can manage. I'll try copying over that ini file and see what happens.

But I am sort of giving up and getting a decent scope for the bench. I've been using a 10mhz BK Precision CRO I got on Ebay for $40 for a couple of years, and the Digilent AD2 when it actually worked on my Linux boxen. But I can't keep dinking around with it when I have projects hanging fire because I can't troubleshoot anything. So I'm getting a Rigol DS1054Z. It'll be here Tuesday.

On Mon, May 21, 2018 at 1:12 AM, Chris Esposito notifications@github.com wrote:

If it loads, that's a good sign.

I can't really explain why the calibration process is failing without being there personally, though, or at least seeing some screenshots that show the voltage waveform at the start of the calibration step.

One alternative could be to short one of the Oscilloscope CH1 DC (Duplicate) pins to CH2 DC, and the other to Power Supply GND. That should short everything to GND and get you through step 2. https://github.com/EspoTek/Labrador/wiki/Pinout Other alternative is to copy your settings.ini from the windows build. Should be somewhere in AppData/EspoTek. Or just leave it. Calibration isn't necessary; just nice.

You're correct in saying that it uses a USB2.0 connector. It actually runs at USB1.0 speeds (12 Mb/s). There should be no advantage at all to using USB3.0 over USB2.0. I use a 2.0 port for my Labrador and have no issues. The reason the guide talks about USB3.0 vs USB2.0 ports is because they're typically driven by different USB controllers. Putting your Labrador on a different controller to your Keyboard/Mouse/Webcam can prevent them competing with one another for bandwidth (and the Labrador requests near-100% bandwidth on some USB controllers that slow down the clock to handle 12Mbps devices) - but it doesn't matter whether the Labrador is on 3.0 and the others are on 2.0, or vice-versa. At least, it shouldn't.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/EspoTek/Labrador/issues/37#issuecomment-390554929, or mute the thread https://github.com/notifications/unsubscribe-auth/ARoafc_xS5OqdVegr0wfRGJy2BiJoli9ks5t0kzGgaJpZM4SOKzu .

--

-+-+-+-+- Jenny Everywhere's Infinite: Quark Time http://quarktime.net

[EspoTek]

Don't worry about the .ini. It's not a calibration problem; if there's no waveform then it's not getting any data from the device at all (calibration helps when your measurements are off by a couple of hundred mV).

If you have a spare USB hub lying around, plug the Labrador (and only the Labrador) into that, then connect the hub to the PC. Unplug all unneeded USB devices.

Other than that, the only solution I can think of is using Android or RPi, or possibly moving the Windows PC to the bench if you really need it.

[drtrigon]

Did the API got added? Is there a docu or an example on how to use available?