Finalizing everything!


No, the prepreorder price was 290€, so you had a voucher about 290€.
Now at the normal preordering the price has become higher (330€), to make sure that the production can be started. In total: 40€ difference...
 
Please make sure you do a lot of research, comparing not just the frequency but the channel information for your carrier against the PLS8 datasheet
I remember this came up before and the conclusion was that one carrier would* work with the European one, another would* work with the US, and another looked like it would work but closer inspection showed it was using a different channel or something and wouldn't work for either.

(*)"would work" meaning that all the technical parts seem to be there but like everything about this project, until someone's actually tried it we can't know for certain.

Thanks for the warning! :)

I don't mind being a guinea pig, and if it doesn't work the GPS and sensors alone would be worth the extra money to me.

The EU version Should Work™ on most Aussie networks in most areas according to these docs:

http://www.gemalto.com/brochures-site/download-site/Documents/M2M_PLS8_datasheet.pdf
http://whirlpool.net.au/wiki/mobile_phone_frequencies
http://www.mobilenetworkguide.com.au/australian_mobile_phone_frequencies.html

This is a summary of the bands the chip supports and what networks it Should Work™ with in Aus.
Code:
GSM  900       : Telstra, Optus & Vodafone
GSM  1800      : (Telstra, Optus & Vodafone all use this band for 4G instead)
UMTS 900  FDD8 : Optus, Vodafone
UMTS 1800 FDD3 : None
UMTS 2100 FDD1 : Telstra, Optus, Vodafone
LTE  800  FDD20: None
LTE  900  FDD8 : Telstra (a handful of sites, utilises spectrum previously used by 2G)
LTE  1800 FDD3 : Telstra, Optus, Vodafone
LTE  2100 FDD1 : Telstra (a handful of sites), Optus (Darwin, Tasmania)
LTE  2600 FDD7 : Optus, Telstra. (TPG have a license but have not announced plans for it.)
 
Ahh, GPS is only available in the mobile version of course. Then I know what to order already since having a map is one of my main use cases and GPS is making my 60+km bicycle tours easier if for some reason my compass isn't enough anymore. Yesterday looking where the sun was standing was enough to find my way back into town fast from no-mans-land, but I may not always be so lucky and carrying my 10'' tablet (which doesn't even have GPS) around in the basket was kind of lame.
I hope OpenStreetMaps gets ported to it soon, I love OSMAND (OpenStreetMapsAndroid) already.
 
Last edited:
Looking at the store page again, it's kinda sad that the rumble and sensors are exclusive to the 4G versions.
Would've wanted them, but they obviously aren't worth the extra 100€ for those who don't have any use for 4G itself. Is that really cutting a bit off the production price or is this supposed to be a way to sell more 4G units?

I can live without them, sure, but I think this may affect the amount of applications supporting these later on.

Emulator already support rumble features, right?
 
I hope OpenStreetMaps gets ported to it soon, I love OSMAND (OpenStreetMapsAndroid) already.

Quick filter in Synaptic package manager in Debian Jessie shows 72 packages for the keyword "openstreetmap" (with no unofficial package repositories enabled). There are also some navigation apps in Debian with OSM suport, for example foxtrotgps and navit.

Foxtrotgps is a user-friendly map viewer with OSM and googlemaps support. Last time I checked (maybe a year ago) both map resources could be used both online and offline. It has some interesting features like route recording in *.gpx file format, wich then can be uploaded manually to openstreetmap.org for further editing. It also supports viewing *.gpx files and various layers of openstreetmap.

Navit is intended to be a full-featured speech assisted turn-by-turn GPS navigation app with routing engine, but requires some time to set up and is a bit rough around the edges. Supports offline OSM and Garmin maps among others. Once set up, it's pretty good. Some time ago I made a test setup. It included a Raspberry Pi (wich is also ARM based just like Pyra) powered from 12VDC cigarette lighter outlet in a car, equipped with a 800x480 LCD screen and NMEA0183 compatible USB GPS receiver. On the software side, I used Debian as the OS, gpsd to feed current position data into navit, espeak for speech output and a perviously downloaded preprocessed OSM map. (I downloaded the map file from a site called navit planet extractor, wich seems unoperational right now. Maybe download.geofabrik.de can be used as alternative.) The setup worked flawlessly, but was a bit clunky with all the cables and stuff on the dashboard.

There is also merkaartor, a map editor for openstreetmap.org. I've never used it.

AFAIK the GPS receiver in the Pyra is NMEA0183 (and gpsd) compatible and supports GLONASS (the russian satnav system), wich together with GPS gives us more accuracy than GPS alone. Maybe date/time data from the GPS receiver can be used to synchronise the local RTC in Pyra. Wait, the Pyra has a RTC, right? I'm sick of the fakehwclock stuff in RPi.

Long story short, in case the standard Debian package repositories will be available on Pyra, OSM is already ported.
 
Sure, that sounds okay with me. Wish I had known that was the case.

Incidentally that comment was made a while back after I had directly asked the question before and received no reply.

But its answered now, so I'm not sure I really see the problem.
 
Maybe date/time data from the GPS receiver can be used to synchronise the local RTC in Pyra. Wait, the Pyra has a RTC, right? I'm sick of the fakehwclock stuff in RPi.

The Pandora had one, so I would be surprised if the Pyra does not. However I am unsure if this was confirmed. It's certainly true that a lot of devices don't have RTC. (Arguably phone that get time from the GPS network... but I still like the RTC).

Regarding syncing time from the GPS, this should be possible. Usually there are 2 ways to set time on a system:

- Setting time manually (simple but time will drift depending on the RTC accuracy)
- Run a NTP daemon (such as ISC "ntpd" or OpenNTPD)

In it's most simple configuration the NTP daemon will connect to a pool of servers using the NTP protocol to setup time when you have Internet connectivity. (you can also run it as a server if you want it to act as a time server for other machines).

Most NTP daemon can be configured for additional time sources. This can be GPS or similar (for example DCF77 is a reference time signal emitted from Germany).

OpenNTPD also has a cool feature that allow to get time from a HTTPS server you trust. The idea there is to get multiple source of information to make sure you're not getting a time from a malicious source. (NTP is not encrypted).
NTP deamon will typically not accept to modify the time if something looks odd (for example if your clock is set to 2016 but a remote server tells you you're in mid 2017!).

Acurate time is actually very important when you're administration a system and for system (HTTPS cert expiry dates...)
 
Most NTP daemon can be configured for additional time sources. This can be GPS or similar (for example DCF77 is a reference time signal emitted from Germany).

I've tried setting up GPS receiver time source with the ntp package in Debian Wheezy, but it did not work with the receiver i used back then (USGlobalsat ND-100S). I think the problem was the lack of PPS (pulse per second) signal from the receiver.
 
OpenNTPD also has a cool feature that allow to get time from a HTTPS server you trust. The idea there is to get multiple source of information to make sure you're not getting a time from a malicious source. (NTP is not encrypted).
NTP deamon will typically not accept to modify the time if something looks odd (for example if your clock is set to 2016 but a remote server tells you you're in mid 2017!).

Acurate time is actually very important when you're administration a system and for system (HTTPS cert expiry dates...)

That's interesting, because ntpd on my Thinkpad X200 with broken RTC (thanks to libreboot I assume) routinely switches to current time after running for a few hours in 1970, after connecting to the internet …
I'd also like to know the problems with manually setting the time (will be inaccurate by about 20s usually) and certificate expiry dates … I guess I must have not seen the 30-second-validity certificates you have …
 
That's interesting, because ntpd on my Thinkpad X200 with broken RTC (thanks to libreboot I assume) routinely switches to current time after running for a few hours in 1970, after connecting to the internet …
I'd also like to know the problems with manually setting the time (will be inaccurate by about 20s usually) and certificate expiry dates … I guess I must have not seen the 30-second-validity certificates you have …

Interesting... RTC clock being broken definitely sucks, even with ntpd as PC will rely on RTC clock for time at boot.
I am no NTPD expert and I honestly don't know how it is supposed to react in your case. If the time difference is small enough, I believe NTPD will accelerate / slowdown time as needed over a certain period of time. (to avoid a sudden time change).

And indeed... no need for "very" accurate time for HTTPS certificate, it mostly just need to be trustworthy. Bad writing / explanation from my part. Kinda mixed everything.

I was thinking more regarding event timing / logs (...). If you administer multiple machines, you want to be able to match the time to determine a timeline of what happened.

I am sure I am missing lots of other scenario/protocol where time is important. For example Kerberos authentication is time sensitive. I think it is common to use timestamp in order to mitigate/avoid replay attacks.
 
Tor uses very short lived certificates.
To be precise, the certificates themselves are valid for a couple of years (to appear to be standard SSL certificates), but Tor nodes discard them after a very short period of time.
 
So with everything that has been said, is it looking like July for a release date? Or more like October? Thanks.
 
Some of the parts have an 8 week lead time, and ED probably wants to give a couple of weeks to maximize the number of orders he gets for the first batch, so my estimation would be about 10-12 weeks, so end of July, possibly August. Maybe later but definitely not any sooner.
 
I still doubt we will see it this year. Suppose parts are ordered end of may then expected delivery is somewhere end of july (assuming the holiday period doesn't delay). Then production, assembly and testing needs to be done. So shipping at best late august.

I can't predict what, but something will go wrong which delays delivery by at least one month. So first pre-orders can expect receiving their units in September according to a best-case scenario. It never goes according to the best-case scenario.

My guess, Q1 2017. I really, really hope ED proves me wrong :)
 
Indeed, and this is why I haven't pre-ordered. There's no benefit to it (it's not any cheaper) other than getting a unit before there's any real software available for it - by which I mean software that has been ported with the Pyra in mind, as opposed to the usual "It builds, ship it" that we had with the Pandora in the early years. And of course, there's the very real possibility that we won't actually get one for a long time anyway. Having been burned by the Pandora in that regard, I'm hanging onto my cash until there is stock to buy.
 
Indeed, and this is why I haven't pre-ordered. There's no benefit to it (it's not any cheaper) other than getting a unit before there's any real software available for it
The benefit is, that there simply won't be any Pyra without enough pre-orders. I think we needed around 500 minimum to make it happen and this point has barely been reached.
Luckily we have enough pre-orders for a relatively small batch now, a bigger one would be more cost efficient though I guess. Let's see if it will be a 1000 units batch after all.
The main reason why I backed this project is, that I simply want to see it happen at all (and I started to miss my Pandora bitterly after having tinkered with some Android devices since of course).
The only thing I ever backed before (apart from paying a bloody lot for the 1Ghz upgrade) was "Driftmoon" and I've done it directly on the devs site without any third partry - it's a good RPG btw.
 
Last edited:
Indeed, and this is why I haven't pre-ordered. There's no benefit to it (it's not any cheaper) other than getting a unit before there's any real software available for it - by which I mean software that has been ported with the Pyra in mind, as opposed to the usual "It builds, ship it" that we had with the Pandora in the early years. And of course, there's the very real possibility that we won't actually get one for a long time anyway. Having been burned by the Pandora in that regard, I'm hanging onto my cash until there is stock to buy.

You're putting yourself first. I get that and it is a legitimate choice. With more people with that philosophy though, it would never happen. So, some day when Pyra consoles are in stock and you can order and receive yours in short order, be sure to thank ED and the rest of the dreamers for putting their money down so that it could happen.

I see the project as getting 'less risky' by the day. Back when ED was doing the primary development work and paying money out of pocket for board and case designs, his risk was very high. When the pre-pre-orders and Prototype purchasers chipped in 70,000+EUR to support the prototyping process, the risk was somewhat lessened, but still very high. Now we're in a general pre-order. A few prototypes have been made and tested. IMHO at this stage with how it's been run, this has better chance of success than the majority of Kickstarter programs. If you want 0 risk, though, maybe waiting until general stock-on-shelves is ready for immediate delivery. However, I hope that demand is so high by that point that ED can raise the prices.
 
it would never happen
Ditto here. I did not pre-pre-order, as it both lasted very short AND there were enough fanboi's stepping up. But I did preorder now to "make it happen" (sold my kindney amd stuff), as we are now talking big figures to start production...

edit: Also chose the 4Gb option. Just because the GPD Win has also 4Gb. Specs rule, unfortunately...
 
Last edited:
I personally find it exciting to be in at the very start. (well earlyish in the pre-orders) I'll enjoy using software and giving feedback, tinkering with the pyra and mucking about.
I reckon we will have good DC emulation pretty early on- some damn fine shmups to be played.
 
Back
Top