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


Lloyd Xmas said:
Damn that's a bummer :eek: That was one the worst things about the Pandora (apart from it's size).
Is the case a tad slimmer?? It looks like a one-for-one copy of the Pandora (minus some button rearrangement) which is sort of disappointing.
Click to expand...
It's thicker :D
 
If whe get the Transparent Case, whe could make my New Patent "Cheatspicker " and place this between Batterie and Batteriecover
This ditnt work whit Pandora because you cant see the Cheat s under the Batteriecover as its not transparent

ad1effcce4ecbe9a1f0138d40ef4a584.jpg



Gesendet von iPhone mit Tapatalk
 
Hey will the Pyra do the whole SD card mass expansion like the Pandora does?

I've impressed a lot of people using my Pandy as a card reader in a tight situation.
 
My laptop doesn't have a USB client port, so I can't test it, but I've never noticed an option to behave as a mass storage device and expose the contents of an SD card. Perhaps I should have a dig in the pandora scripts folder for one that does it.
 
Just had a dig; the script is called op_storage.sh in the usual place, and all that does in practice is insmod a module called g_file_storage. That module doesn't exist on my Arch setup, but it may be relatively standard in more user-friendly distributions, I dunno.

It's a little bit hacky - it relies on you not modifying the files while the zenitfy dialogue is up (i.e. it hasn't rmmod'ed the module), and nothing else in the background doing so, and who knows when some big backgrounded package decides to update its appdata? But if you've no PNDs open and don't touch the unit while you're using it, it should be fine in practice.
 
Last edited:
levi said:
It's a little bit hacky - it relies on you not modifying the files while the zenitfy dialogue is up (i.e. it hasn't rmmod'ed the module), and nothing else in the background doing so, and who knows when some big backgrounded package decides to update its appdata? But if you've no PNDs open and don't touch the unit while you're using it, it should be fine in practice.
Click to expand...
LOL - just the sort of thing systemd likes to do, mind you first task for me is installing Linux on a Pyra if its the SystemdOS version of Debian in use...
 
What about software defined radio from the T.R.R.S. jack? I found another thread that suggests it doesn't really work on Pandora. Obviously the electrical ratings and fidelity would be severely limited when compared to specialised equipment but I dream of using my cellphone as an oscilloscope or variable power supply. Maybe connect it to coax or generate random numbers from radio noise. I'm sure there are a lot of cool applications even within the audio spectrum, and the precision would probably be fine beyond the normal audio range since it would be interpreted by software. Just an idea.

https://pyra-handheld.com/boards/threads/sdr-on-pandora.75704/
 
Using the microphone ring of the TRRS jack might work as an osclilloscope relatively easily, although someone would probably need to write applications that display the live data, rather than record it for later playback like you would with audio data. I don't believe you'd need SDR for that.

Power supply is less likely to be developed from the headphone port though - the only power output is a little for powering the microphone. The USB ports can give you a steady 5V though, and perhaps the current can be limited like any half-decent bench supply can do, but that would require a lot of low level research. With a modicum of external electronics, you could use that 5V supply to drive an up-to-5V-ish variable power supply though, and I suspect that would be a more enlightening engineering project than delving into the internals of the USB subsystem.
 
Ok, thanks for clarifying that. Are physical adapters (pass-through) commonly available from U.S.B. to standard radio connectors? I was probably wrong to lump electronics functionality together with S.D.R. but my initial concern was just driver support by applications like GNU Radio and GNU Octave. Maybe these programs already work with pretty much every audio and U.S.B. controller, but that assumes the U.S.B. controller will even accept requests to operate at non-standard frequencies per channel. I really don't know how this stuff works but based on your response, I guess it should work? Does anyone know why it does not work on the Pandora, or maybe the information I found was out of date?

Regarding software, interpreters could be, or perhaps already have been, built for specific applications like electronics work and entropy generation. In those cases, perhaps they would be best built on top of Octave, but I am not really familiar with it. I only mentioned it along with S.D.R. because the concept seems more developed and they are essentially the same from interface to driver; technically, digitising or emulating electronics equipment would not be S.D.R. because there is no radio component. Maybe this is "software defined electronics"?

For me, the romance is in optimising versatility (i.e. not needing external electronics). From a versatile system standpoint, I would like to replace the concept of an "audio interface" with an "analogue interface". It would certainly be possible to use an external U.S.B. interface, like HackRF, but it would be nice to get the most use possible out of the hardware I always carry with me. When I need something that just isn't possible with the Pyra's controller(s), then I will plug in the U.S.B. interface.

When I get the chance, I will try to find more info on what specifications would be useful for some electrical applications and how they could be compared to similar standards for audio and U.S.B. controllers. Not really something I know much about but I'll see what I can find.
 
A radio works by having a wobbly circuit - one that likes to resonate at a specific frequency. You can control what frequency it resonates at using a big knob, usually connected to a variable capacitor, and you hook it up to an antenna. Something about how strongly it wobbles defines the signal, at least in a simple AM radio or analogue TV. Try emulating that in software, and you experience difficulties quite quickly. I played around with a wobbly program in an experiment with making a digital synth, but was killed by the small mistakes in rounding each number to a fixed precision that computers require, such that I couldn't even get a steady static wave out of it, so I went back to faking my waves using the sin() function.

That's software defined modulation though, and that's relatively pedestrian maths. To do software defined demodulation though, you need complex mathematical tools like fourier transforms and other things I've never even heard of, and that to my mind is the key part of software defined radio, as I understand it. Such things are difficult to do as human beings, and slow even for computers to do. That's why we never saw it on the Pandora as I understand it, because it needs a lot of computing power to be able to do it in real time, so that you can actually tune into a live signal.

Maybe the Pyra will be fast enough to do it. I don't really understand the maths, so don't know why PCs today can do it, but I suspect they're farming bits off to programmable GPUs and other parallel processors that didn't really exist a few years ago, and may still not be there on the Pyra.

But luckily, you really don't need to do any demodulation to act as a digital oscilloscope. You just need to be able to sample the signal and then show it immediately, and to make a really useful live oscilloscope, you'd need to implement triggers, which I think is really a pattern matching problem. I'd hope the Pyra will be able to do that, and perhaps even the Pandora could if anyone had cared to code it all up.

I do see a power supply project as being more difficult to simulate just using software though - when the USB port's only really designed to supply 5 volts, getting it to do anything else with software is pretty much impossible, unless there's a way to trick the firmware into doing something non-standard.
 
"But luckily, you really don't need to do any demodulation to act as a digital oscilloscope. You just need to be able to sample the signal and then show it immediately, and to make a really useful live oscilloscope, you'd need to implement triggers, which I think is really a pattern matching problem. I'd hope the Pyra will be able to do that, and perhaps even the Pandora could if anyone had cared to code it all up."

I wonder if this is so. I don't won't want to harm my current Pandora. I use it daily. There's no way that I'd be able to use this as an digital oscilloscope...but if that was possible? We'd sell a a heck of a LOT more PYRAS. Maybe ED needs to look into this possibility/function?
[doublepost=1475459037,1475458758][/doublepost]If we can also market it to the scientific community. We could have a portable workbench..
 
there are a number of USB oscilloscopes, available - some even with Linux software or open design and even with capture (ie their own memory) trying to do an oscilloscope through the mic port would be much like PC sound card "oscilloscopes" of old - basically of very limited use...

I believe http://www.bitscope.com/ has arm support...
 
You must log in or register to reply here.

Similar threads

rygD
What will Pyra replace for you?
2 3
Replies
56
Views
8K
Klumpen
K
Binky
A new chapter will be written...
Replies
15
Views
6K
Binky
Binky
undexsym
Survey for Pyra owners
Replies
14
Views
5K
rootshell
R
A
Which software do you miss on Pyra?
4 5 6
Replies
116
Views
24K
vampire8bit
V
fantomid
Advertizing in magazine
2
Replies
20
Views
5K
mius
mius
Back
Top