What will a Pyra be able to do that the OpenPandora can't do now?


Also, don't forget that apparently the Pyra can apparently measure the voltage coming in through its USB ports, up to 5.5V/6V easily, and also be able to measure the current coming in to the battery, and by wiring one 5V out to another via some load, could measure resistance using the voltage drop. So it could function as a kind of VOC/multimeter, albeit with crippled current measurement that you can't use in-situ.
 
Also, don't forget that apparently the Pyra can apparently measure the voltage coming in through its USB ports, up to 5.5V/6V easily, and also be able to measure the current coming in to the battery, and by wiring one 5V out to another via some load, could measure resistance using the voltage drop. So it could function as a kind of VOC/multimeter, albeit with crippled current measurement that you can't use in-situ.
terrible idea, honestly... the great thing about having USB is it allows you to electrically isolate devices from delicate valuable electronics like the Pyra, if you do want to experiment with interfacing electronics, why not think about using a iCEstick fpga this can act as both USB interface and an interface to your custom circuit...

...and that's if something like bitscope's various analysis tools can't do what you want...
 
Very interesting stuff. Thanks for the detailed explanation, Levi. And for the link, Codifies. BitScope looks like a great option, I will be sure to give it a try. I definitely don't know anything about the specifics of how what is possible but I have previously looked into specialised hardware for this sort of signal processing. It is definitely possible to do amazing things with nominal system specs, but it is quite possible that discrete logic chips are used for the tricky processing. If this is the case, and assuming the Pyra does not include this logic, I would agree with FlapJack that this is something to be added in future designs.

For serious applications, I would certainly use a specialised solution, such as the BitScope products or HackRF. I imagine these would handle most of the system resource load as well and function properly with a Pyra or Pandora, please correct me if I am wrong. Obviously another consideration is the antenna or electrical probe/clip, but that would be necessary regardless of the interface. If this sort of specialised tech could be built into the Pyra, I would happily pay an extra 50% for it. Like the mobile data, this could be an optional controller to replace the standard audio controller. Alternatively, new U.S.B. specs like 3.1 and Type-C seem to support high output currents. I'm not sure how precisely the controllers can be configured but I know that there are provisions for negotiating additional power over multiple wires. 100W at 12V-24V would be perfectly useful as a variable power supply, or perhaps as a variable resistor through loop-back. I think the specs might cut off at 20V but this is something somebody else would need to look into in the future. Obviously these won't be on the current Pyra version but it may be a better method than replacing the audio controller, at least for electronics applications.

As for what a normal sound controller might be possible of, I believe using a normal sound controller would limit the theoretical frequency range to at least 20Hz-20kHz, in line with the audible range. As I said before, less precision may be required if a program is interpreting the data rather than a human. This range has some uses for radio applications but probably not many for electronics. I believe the usable sample rate of a 192kHz sound controller would translate to an oscilloscope sample rate of 48-96kHz (Link-1 below). Audio line level for consumer audio products is supposed to be 0.447 Vpk nominal and 1.736 Vpk nominal for professional audio products (Link-2). Max voltage, corresponding to decibel level, seems to be a tricky point for consumer sound controllers due to an industry arms-race for volume. 5V seems to be a reasonable expectation for voltage output but some sources report 24V or 60V for reasons I do not understand (Link-3). Input rating for an audio controller seems to be much lower than output since it would be "mic level" rather than "line level". I found one source that suggests 447 mVpk, but I could not corroborate this (Link-4).

There are apparently many resources describing the adaptation of a P.C. for use as an oscilloscope but I cannot be sure how safe or accurate the information is. One resource I found suggests that input can be attenuated significantly but the laptop may be at risk despite resistive circuitry (Link-5; see "NOTES:" at bottom of article).

Again, I really don't know much about this technology or the basic sciences. This sort of education is one of the reasons I am so interested in having these versatile resources available. My ideas can be taken with a grain of salt, but they do seem useful to me. Maybe others will find them useful as well.

Link-1: http://www.ni.com/white-paper/4333/en/#toc2

Link-2: http://electronics.stackexchange.co...nge-of-a-standard-headphone-jack-from-a-phone

Link-3: http://electronics.stackexchange.co...-typical-max-voltage-out-of-a-pc-speaker-jack

Link-4: http://electronics.stackexchange.co...he-typical-max-voltage-for-sound-card-line-in

Link-5: http://www.instructables.com/id/Use-Your-Laptop-as-Oscilloscope/?ALLSTEPS
 
don't forget that with SoC devices (system on a chip) normally peripheral devices like sound controllers are actually on the die with the cpu (they are literally (almost) complete *systems* on a (single) chip), while having dozens of different hardware options might sound attractive, "just" designing the one system is a really complex exercise, making it work with different radio options multiplies complexity still further. All of this could potentially cause massive delays and significantly increase the cost for everyone.

By far the better way of thing about it is not to have one box that can do everything (and some things that many won't have a use for) but rather think of the device as the coordinator for whatever devices meets your particular needs. Don't underestimate the speed of USB3...
 
That is a good point. I don't know much about engineering electronics, maybe it is not worth the trouble in the foreseeable future. My instinct is to imagine the best product possible before accounting for reality, but it is also important to consider time tables. If it is possible to develop this functionality in later designs, I think it would be a great asset, but it is certainly not a deal-breaker for me even though these are technologies I am specifically interested in. Ratcheting up production is definitely more important.

For my part, I will just plan on using external peripherals for S.D.R. and S.D.E. It is not a problem at all, just slightly less than a theoretical ideal. As long as the external peripherals are compatible and software like BitScope and GnuRadio support the Pyra's audio controller, my concerns have all been addressed. Bench-marking will obviously have to wait for the time being but I hope some early recipients will take a swing at it (safely) and post their results. Thanks for pointing me in the right direction, I hope this conversation will also encourage future readers to try these exciting technologies.

In the interest of tying up loose ends, I seem to recall that U.S.B. 3.0 operates somewhere around 2.4GHz (and can suffer from interference from WiFi if the shielding is bad) so I don't know if the controller would be technically capable of communicating functionally on an arbitrarily lower frequency even if physical pass-through adapters to analogue connectors are readily available. Using the audio controller seems to be a standard practice so I will assume the U.S.B. controller is at least not practical for S.D.R. applications. Perhaps it could be useful for higher-voltage S.D.E. applications, like the variable P.S.U. or variable resistor, but I will leave that question for a later date.
 
having the host directly controlling a circuit like SDR isn't quite what I was meaning, anyhow I assume you know about devices like this https://www.adafruit.com/product/1497 (no idea if there is Arm kernel support?)

I'd encourage you to play with an iCEstick as they are cheap and its not like any kind of electronics or programming you're probably used to, but with application you can rapidly make nice "glue" interfaces between hairy hacks on your breadboard and your computer... you can even created a limited data buffer you name it!

I have one of the slightly more capable boards that are compatible with the iCEstick so I will definitely be trying to get IceStorm working on the Pyra!
 
Output >720p over HDMI vs. 480i/576i S-Video -- having a full desktop while docked where it would otherwise be difficult on the traditional TV-out. HDMI isn't going anywhere soon (obsolescence), so it has that over the Pandora.
 
About using Pyra as measurement instrument... I think there should be something between computer and the world. For digital electronics: Sigrok + fx2lafw? (Cypress-based analyzers are relatively cheap) - although I have never managed fx2lafw to work with my Saleae-clone.
Unfortunately Sigrok-friendly analog devices may cost a small fortune.
 
Out of curiosity, could there ever be a possibility of an x64 CPU, like something Cherry Trail perhaps?
 
Out of curiosity, could there ever be a possibility of an x64 CPU, like something Cherry Trail perhaps?
Could there be, sure. The idea of a modular CPU board makes this possible. However who knows were we will be with the project when the time comes.
 
Pointless, but oh so cool. Will that be relatively easily done?
For a specific game, yeah, it can be done. You react to some specific event in game to change LED color.

For Ambilight like behavour, it's more difficult, as you have to grab the framebuffer and analyse it to see what is the dominant color (and on some specific region of the screen also, for more awesomeness) to then change the color of the LED.
 
For a specific game, yeah, it can be done. You react to some specific event in game to change LED color.
That depends on what system processes are in control of the LED colours, assuming we have one to indicate battery power that way or SD card access or whatever. It would need to be told to allow us to set the colours temporarily, or have an API that lets us use it to set the colours, or something else to make it play nice with us.
 
That depends on what system processes are in control of the LED colours, assuming we have one to indicate battery power that way or SD card access or whatever. It would need to be told to allow us to set the colours temporarily, or have an API that lets us use it to set the colours, or something else to make it play nice with us.
Yeah that was the thing I was wondering about, how would you set the LED colours anyway if they're gonna be used by battery etc.
 
Well, I suspect that will end up being hammered out one evening on IRC when a few good coders have their systems. I tried creating a thread to hash out ideas of how it would look, but I probably made it too complicated, and it's hard to judge without having a unit in your hands anyway.
 
Back
Top