Author Topic: EEVblog #858 - Red Pitaya  (Read 34616 times)

0 Members and 1 Guest are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26752
  • Country: nl
    • NCT Developments
Re: EEVblog #858 - Red Pitaya
« Reply #25 on: March 08, 2016, 08:00:17 pm »
As a web developer myself, I can only begin to imagine the hoops they must be jumping through just to get that kind of thing working at all.
A simple solution is to stream the waveform display as a video feed to the web-browser. That way the web interface is no more complicated than a web page with embedded video.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline TubiCal

  • Newbie
  • Posts: 5
  • Country: de
  • Tube Tinker & Mad Musician
Re: EEVblog #858 - Red Pitaya
« Reply #26 on: March 08, 2016, 08:47:59 pm »
Watching your EEVBlog2 ExTended version....

I was thinking of buying that thing, as i read some nice elektor articles about it. Thanx to you, Dave, and also for your video(s) on this thing, as you just saved me much money :)

Next is: that builtin FPGA is not really accessible by the user....you need to cross-compile your code, according to the linked git-hup page by redpitaya...but that is only for ready to compile code. So you need a FPGA IDE to utilize that thing ->  Vivado Lab Edition made by xilinx....with all their price-policy....No way.

Why they come up with such a silly thing. Combining two complete different arcitectures and only (and also barely) supporting just one...?? But advertising the FPGA capabilities like they have their own IDE...WTF???!?

In fact they have nothing, beside that scratch rip-off "visual-programming" in which i haven´t found FPGA stuff...

Just tried to access this visual....blah...blah..got this:

Error: Connection was destroyed by application
    at /data/wyliodrin/startup.js:360:19
    at /data/wyliodrin/helpers/logger.js:100:24
    at /data/wyliodrin/node_modules/raven/lib/client.js:128:15
    at /data/wyliodrin/node_modules/raven/lib/parsers.js:27:9
    at /data/wyliodrin/node_modules/raven/lib/utils.js:166:36
    at fs.js:272:14
    at Object.oncomplete (fs.js:108:15)

hahaaa...obvious..i don´t have that board....but i wanna know if the FPGA will be accessible through this, if not BiGTime FAIL...

It looks to me like a complete "we don´t know what we´re doing" project.

cheers,
TC


Because Tubes run hotter than any 1/2(0nDUCK<>
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 400
Re: EEVblog #858 - Red Pitaya
« Reply #27 on: March 08, 2016, 09:09:45 pm »
Seems like a great piece of hardware hampered by immature software
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #28 on: March 08, 2016, 09:14:30 pm »
So you need a FPGA IDE to utilize that thing ->  Vivado Lab Edition made by xilinx....with all their price-policy....No way.

Vivado WebPack is free-as-in-beer for small Zynqs.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: EEVblog #858 - Red Pitaya
« Reply #29 on: March 08, 2016, 09:19:32 pm »
As a web developer myself, I can only begin to imagine the hoops they must be jumping through just to get that kind of thing working at all.
A simple solution is to stream the waveform display as a video feed to the web-browser. That way the web interface is no more complicated than a web page with embedded video.

Nah. A display like that needs lossless compression and that would never work across WiFi/whatever - too slow.

And no, you can't invent special data compression schemes. It has to run in a standard browser with no plugins.

It's easy enough to find out though: Have a look at the page source and see if it uses an HTML canvas plus a whole load of JavaScript to download data. Anybody got one to look at?

« Last Edit: March 08, 2016, 09:27:28 pm by Fungus »
 

Offline TubiCal

  • Newbie
  • Posts: 5
  • Country: de
  • Tube Tinker & Mad Musician
Re: EEVblog #858 - Red Pitaya
« Reply #30 on: March 08, 2016, 09:33:48 pm »
So you need a FPGA IDE to utilize that thing ->  Vivado Lab Edition made by xilinx....with all their price-policy....No way.

Vivado WebPack is free-as-in-beer for small Zynqs.

Hmm, need to check for that, thanx :)

Done, looks cool.....need to test that!

Here´s the link if anybody is also interested in this:

http://www.xilinx.com/products/design-tools/vivado/vivado-webpack.html

I also found some measurements on how the ADCs perform...(not very low-noise within audio range)
sorry german only - check post 49 for F(t) plots (c&p doesn´t work properly so you need to go to #49 maually,sorry)

http://www.qrpforum.de/index.php?page=Thread&threadID=10089&pageNo=3

There´s also a guy who done a dev SD image to make programming easier...but not even something like a real IDE

http://pavel-demin.github.io/red-pitaya-notes/debian-ecosystem/
 

cheers,
TC
« Last Edit: March 08, 2016, 09:45:13 pm by TubiCal »
Because Tubes run hotter than any 1/2(0nDUCK<>
 

Offline sram

  • Newbie
  • Posts: 3
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #31 on: March 08, 2016, 10:21:23 pm »
This thing looks so cool. I really want one just don't have a use for it yet. If the SDR could go higher then I could use it right away.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #32 on: March 09, 2016, 01:12:32 pm »
I'll just throw a reminder to Australian readers of this thread that someone (unknown to me) is selling an Analog Discovery on Ebay at the moment. I bought something from them and I was happy with the transaction.

There's only one. http://www.ebay.com.au/itm/Digilent-Analog-Discovery-Circuit-Design-Kit-Oscilloscope-Logic-Analyzer-/231867995678?hash=item35fc68d61e:g:BmYAAOSwqYBWmhAv

Seller claims it is unused.

Its the old one, not Analog Discovery 2.

There is very little practical difference between the AD1 and AD2: (a) a variable rather than a fixed power supply and (b) fancy new case.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #33 on: March 09, 2016, 01:56:41 pm »
I order both Red Pitaya and Analog Discovery 2 , just to compare them and see if they can be used to do anything serious.
Red Pitaya looks very pre mature, but the web interface attracts me due to that i make a lot of remote control and measurements.

I can help you there.

As a useful bench instrument

The AD fits the bill, the software is the best I've ever used on any USB instrument, plus it just plain works, I can't ever remember having any problem with the software or the hardware. It includes LA, digital pattern generator, scope and signal generator, and all can be run concurrently. The only thing I recommend is to get the BNC adapter, using the differential inputs alone is quite restrictive, and suing the BNCs affords a greater scope bandwidth.

The RP is little more a toy as far as being a useful bench instrument goes. Unlike the AD, it's not plug and play out of the box, you will need to make up an SD card and fiddle around figuring out the device's IP address, for some reason it doesn't register with my DNS or resolve as a broadcast on my LAN. Being able to access readings remotely may be a useful niche use for the RP. I am fairly certain that in its current state as a bench instrument even a beginner will be disappointed. However, as an SDR I can see this being a good use case, although it lacks front end preselection filters which is likely to be a problem if used directly on HF. Just using my finger as an antenna on the Ch1 attenuator handbag connector, I can pick up MW AM transmissions. I can also see its value as a low-IF or ZIF as part of an RF system. As an SDR was perhaps the only time I've felt that the RP excelled in any way.

As a tinkering device

If you are interested in hard core development, have reasonable Linux dev skills and are patient, then the RP might be what you want, but unlike the AD it's an unfinished article. The hardware and core software seem reasonably stable, and there is out of the box a set of reasonably useful FPGA IP configs that you can use without even having to touch any FPGA dev tools: that in itself is worthy of note. But beware, the instructions on building a functioning dev environment are woefully inaccurate and/or out of date. Having said that, my own use case is using this as part of a one off OEM design and as such there was little point in reinventing the wheel when hardware like this is already available.

For programming, the AD offers an API, but I'm not sure what you'd want to do more than the excellent software does already. I am not sure how well it can practically be used for continuous sampling, an essential requirement for SDR use, but the facility to do so is discussed briefly in the SDK. That might be a nice project for someone!

Conclusion

Both devices can be used under Windows, Linux (x86 & ARM) and OSX. The AD is USB high speed and bus powered, whereas the RP is Gig Ethernet or WiFi with the right adapter, and needs its own power supply.

In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.
« Last Edit: March 09, 2016, 05:37:06 pm by Howardlong »
 

Offline yym

  • Contributor
  • !
  • Posts: 23
Re: EEVblog #858 - Red Pitaya
« Reply #34 on: March 09, 2016, 02:05:19 pm »
I was looking for something like this, FPGA with ARM core + ADC/DAC , I'd prefer Alterea though.
This would be a very good choice if it was fully open, schematic, layout and whatnot.
Without, it is worthless.

Come on.. , the apps are useless, they tried to implement a sort of app store with licensing and demo/trials LOL, they failed big time.
Visual programming interface.... yeah, because that is what one wants to do with a GHz dualcore ARM FPGA ... write silly code in a shity graphical web interface, yup pretty much...

Just sell this as a development board, with open everything.

I would buy it, it is actually cheap compared to similar (more) professional boards.
 

Offline woox2k

  • Regular Contributor
  • *
  • Posts: 54
  • Country: ee
Re: EEVblog #858 - Red Pitaya
« Reply #35 on: March 09, 2016, 02:39:52 pm »
Dave, are you sure your router does not isolate wifi/cable clients from each-other in order to improve security (some routers do it by default) That would explain why you weren't able to connect to the device over wireless.
You cannot blame Red Pitaya for all the problems you experienced because it would be impossible to guess and work around every different network configuration some people might have. I do agree that using browser/ethernet as only way of using it out-of the-box is a very bad idea on it's own and there will be a lot of disappointed customers. Same thing goes for using all available screen space. Most people have different screen resolutions and it's user interface should be very flexible to fit them all. Fact that it runs on web browser makes it even worse because desktop API's are way more flexible.
Either way if one expects to sell a device that would work perfectly out-of-the box it should have it's own screen and input system to remove all problems that might occur while user is trying to connect to it. To make it short, most user friendly scope is a standalone scope  :)
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #36 on: March 09, 2016, 05:19:08 pm »
There is very little practical difference between the AD1 and AD2: (a) a variable rather than a fixed power supply and (b) fancy new case.

And, ISTR, the most important difference: a better USB connector.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #37 on: March 09, 2016, 05:24:33 pm »
In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.

I'd also look at the effectiveness of the AD internal scripting JavaScript library. It might be usable when making, say, a small ATE system or a curve tracer. I believe it also has a more conventional API for C/Python et al.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #38 on: March 09, 2016, 05:51:14 pm »
In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.

I'd also look at the effectiveness of the AD internal scripting JavaScript library. It might be usable when making, say, a small ATE system or a curve tracer. I believe it also has a more conventional API for C/Python et al.

Totally agree with both.

Your AD (python) curve tracer:
https://ez.analog.com/community/university-program/blog/2013/12/07/analog-discovery-bjt-curve-tracer-program
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #39 on: March 09, 2016, 06:22:28 pm »
In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.

I'd also look at the effectiveness of the AD internal scripting JavaScript library. It might be usable when making, say, a small ATE system or a curve tracer. I believe it also has a more conventional API for C/Python et al.

Totally agree with both.

Your AD (python) curve tracer:
https://ez.analog.com/community/university-program/blog/2013/12/07/analog-discovery-bjt-curve-tracer-program

Very nice!
 

Offline chris_leyson

  • Super Contributor
  • ***
  • Posts: 1541
  • Country: wales
Re: EEVblog #858 - Red Pitaya
« Reply #40 on: March 09, 2016, 06:29:36 pm »
One of the reasons I bought a Red Pitaya was because of the wifi interface, it eliminates another source of common mode noise, i.e. the USB or ethernet cable to your PC, I'm just left with cleaning up the power supply.

The HTML interface is a clever idea, no special software needed just a browser, it's a bit slow though but how else do get any useful data into an iPad, not through bluetooth, Apple made sure they crippled that.

Fitted a Sunon Maglev 5V 25x25mm fan onto mine, a pair of M2.5 cap heads will cut just enough thread between the heatsink pin fins so it won't drop off.

I have to check which Edimax wifi dongle I was using, some work and some don't.
 

Offline vodka

  • Frequent Contributor
  • **
  • Posts: 518
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #41 on: March 11, 2016, 07:58:15 pm »
Quote
The HTML interface is a clever idea :palm:
   

HTML is an language interpreted that is loaded over a browser who surely will be written with other  language interpreted (Net or java).
On resume, more slow than the horse's bad with more fails than a shootgun's donnybrook.

Code: [Select]
no special software  You change the snots by slobbers , you haven't got the physical sofware in property ,else they have your program at the cloud and you have that be connected permanently or else don't work.

I have never heard the board's Pitaya, but the first effect have been very wrong(SCAM) . I think that they go off  the clever.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3634
  • Country: us
  • If you want more money, be more valuable.
Re: EEVblog #858 - Red Pitaya
« Reply #42 on: March 11, 2016, 08:02:01 pm »
Seems like a great piece of hardware hampered by immature software
Yes, I would love to see the FRA and LCR functions mature. In the meantime, I will be looking for more capable solutions for that.

Sent from my horrible mobile....

Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #43 on: March 11, 2016, 08:49:51 pm »
HTML is an language interpreted that is loaded over a browser who surely will be written with other  language interpreted (Net or java).
On resume, more slow than the horse's bad with more fails than a shootgun's donnybrook.

That is wrong in so many ways and on so many levels that it is difficult to know where to begin to correct it.

The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline vodka

  • Frequent Contributor
  • **
  • Posts: 518
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #44 on: March 11, 2016, 09:44:49 pm »
Quote
The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.

Simply ,that is a design a pure conversational ,at Christian, the software is done a polling continually to the server. Now you imagine that connected at same time 10 k of users , the server collapse it.
Because as we saw Dave's video the software was freeze or went very low to load, due to a bad logic design

Quote
The browser itself is obviously not written in an interpreted language. Java and MSIL are NOT interpreted language. They are called byte code. Also, C++.net can be compiled to native code.

Java at the 90% is interpreted, when you compile the source java that is converted to OPCODE'S JAVA(no is the traaditional ASM) and when you executed the program the opcode's java are translate to real assembler machine in time-run. And the same with the .Net if you don't change the settings compiler.

Example interpreted language  :

       Spanish(native) to English(Language mid)  to Chinese(native)

Example compilated language:

    Spanish(Spain) to  Spanish(Cuba)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #45 on: March 11, 2016, 10:08:19 pm »

Fitted a Sunon Maglev 5V 25x25mm fan onto mine, a pair of M2.5 cap heads will cut just enough thread between the heatsink pin fins so it won't drop off.


The one I've been using sounds the same, RS part number 7588204 mfg pn MC30060V1-000U-A99. They're bloody noisy when used with the acrylic enclosure!

Wireless, I have the prescribed Edimax EW-7811UN which I tried after getting it working on Ethernet, but after 3/4 of an hour gave it up as a bad job.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #46 on: March 11, 2016, 11:05:58 pm »
Quote
The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.

Simply ,that is a design a pure conversational ,at Christian, the software is done a polling continually to the server. Now you imagine that connected at same time 10 k of users , the server collapse it.
Because as we saw Dave's video the software was freeze or went very low to load, due to a bad logic design

In which case it is nothing to do with HTML and nothing to do with implementation of HTML and nothing to do with the browser. It is the application.

No surprises there.

Quote
Quote
The browser itself is obviously not written in an interpreted language. Java and MSIL are NOT interpreted language. They are called byte code. Also, C++.net can be compiled to native code.

Java at the 90% is interpreted, when you compile the source java that is converted to OPCODE'S JAVA(no is the traaditional ASM) and when you executed the program the opcode's java are translate to real assembler machine in time-run. And the same with the .Net if you don't change the settings compiler.

For Java, no.
  • Java has always been JITted, which is a 30 year old technology developed by L Peter Detusch for Smalltalk.
  • And 15 years ago Java got significantly faster due to the Hotspot JVM technology developed for Self.
To understand the significance of Hotspot, consider that if the same techniques are applied to optimised C code running on processor X, then the code can run faster when running inside an emulation of processor X that is itself running on processor X. In other words, with Hotspot type techniques, an emulated processor+program is faster than the real processor+program. See http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

Obviously neither C/C++ nor C# can do that since they can only do staric opimisations based on what the compiler guesses the code will do. HotSpot optimises what the code actually does.

There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #47 on: March 12, 2016, 07:52:53 am »
I realise I'm somewhat of a Luddite, but I've yet to see any real world evidence, as opposed to contrived examples and a very few edge cases, that the profile based adaptive optimisation provides any gains in an overall sense compared to static optimisations.

We've had similar techniques in the database world for a couple of decades now, the main problem with these techniques is lack of determinism which is a serious frustration when troubleshooting particularly non-functional facets of a system. All that code you diligently tested is now doing something different, but not all the time. I'd much rather have a consistently slowly performing system to troubleshoot I can reproduce than one that sometimes randomly starts running ten or a hundred or a thousand times slower.

My point is that something you non-functionally tested in lower environments is more likely to behave differently in higher environments because it's virtually impossible to come up with a practical test matrix.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #48 on: March 12, 2016, 09:14:22 am »
I realise I'm somewhat of a Luddite, but I've yet to see any real world evidence, as opposed to contrived examples and a very few edge cases, that the profile based adaptive optimisation provides any gains in an overall sense compared to static optimisations.

That would be an extraordinarily difficult thing to do with a real-life application - how can you meanigfully compare, say, a Java application with a C application? In all such cases the quality of the libraries and application, the development timescale and availability of staff would totally dominate any results.

However, the key point about the HP Labs report, http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html is that it unambiguously shows the surprising power of HotSpot-class techniques. It destroys the ignorant prejudice that "Java has to be slow because it is interpreted".

I say "surprising" because they weren't looking for such a significant result. Some commentators have even described it as "accidentally becoming a viable C compilation technique", but I think that is overblown!

I've personally witnessed key portions of  an application-server based code become 3 times faster as Hotspot kicked in. BTW, as you know, realistically it has to be server based, not embedded!

Quote
We've had similar techniques in the database world for a couple of decades now, the main problem with these techniques is lack of determinism which is a serious frustration when troubleshooting particularly non-functional facets of a system. All that code you diligently tested is now doing something different, but not all the time. I'd much rather have a consistently slowly performing system to troubleshoot I can reproduce than one that sometimes randomly starts running ten or a hundred or a thousand times slower.

I'd argue that your system architecture's function must be insensitive to detailed timing delays, since that's what will occur in production. Of course, when benchmarking performance, it is vital to "warm up" a HotSpot JVM before doing the performance test, but that is neither difficult nor lengthy.

Quote
My point is that something you non-functionally tested in lower environments is more likely to behave differently in higher environments because it's virtually impossible to come up with a practical test matrix.

In that case the system architecture and implementation is badly defective, unless you restrict "differently" to mean "slower but still correct".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 5980
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: EEVblog #858 - Red Pitaya
« Reply #49 on: March 12, 2016, 01:08:25 pm »
It seems they have a business model focused on the Hardware and accessories (with some third party contribution), therefore saying that a closed hardware detracts from the product is way too narrow. One can argue one way or the other, but IMO the effort put into such compact DAQ must be rewarded in some way.

Also, developing a polished GUI is not an easy task, but the large number of drop-down menus, the large buttons, the apparent empty areas (for a desktop browser at least) and the "wheel" at the bottom are a clear giveaway they were trying to cater tablets or modern notebooks and their touchscreens.

I agree with others regarding the Wifi issues: it is really difficult to address all different configurations and their pitfalls, and I have the impression your router is getting in the way. This is traditionally addressed by FAQs and documentation, but it is not easy to do in a newly released product (which I think this is, but maybe I am wrong).

Interesting to see the design decision to go for a dual A9 core integrated into a FPGA - perhaps the compactness was a very important factor. In other times I would have never expected to see this combination simply due to the power density.

All that said, IMO the issues shown in the video (and corroborated by others) make the product unusable as a DAQ.
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf