Finalizing everything!

[Djoga'Ro]

..., one last question.

For sure.

 

[rSl]

yeah!
were so close now to PREORDER, wooohooo!!!

i'll order (hopefully in time) a superawesome beauty regular edition with 4gb of ram.
larger ram is a verry good thing imho, as linux always uses nearly all the available memory as cache to speed
things up by default.
as i'm a privacy minded citizen, i just couldn't convince myself for a mobile-modem with attached sensors and gps.
to be clear, i think the pyra using 3g/4g will be one of the most secure mobile comm devices one can get right now, but i just
personally can't trust *any* actively data-sending device combined with sensors (audio/video/location/rotation etc...) these days.
maybe there will be an fpga baseband with full opensource some day, then perhaps i'm in for a mobo swap too.

once again, woooohooooo! it's sooo cool that this awesome project is now engaging this important step!
all the best for all preordering pyrates, arrr!!!!

 

[EvilDragon]

Thank you @EvilDragon, one last question. If you decided to launch it, could I buy a "normal" Pyra preorder and then change it for a "low specs" Pyra?

Yes, that's how it's planned

 

[Xcl4m4t10n]

Thanks @EvilDragon, preorded .

 

[ljones]

Ok. I just pre-ordered (I think) and used my pre-pre order voucher. So in total it came to about EUR40. Did something go wrong or ?

 

[CRANKY K.]

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...

 

[jbit]

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.

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.)

 

[Klumpen]

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.

 

[Faust]

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?

 

[Kolbász]

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.

 

[FBnil]

It's just his silence on the issue is deafening.

He is taking a day off... he has been working nonstop the last weeks... just 1 day off... won't you allow that?

 

[directive0]

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.

 

[the_marshal]

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...)

 

[Kolbász]

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.

 

[CrystalGamma]

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 …

 

[the_marshal]

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.

 

[Plume]

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.

 

[DougOnEarth]

So with everything that has been said, is it looking like July for a release date? Or more like October? Thanks.

 

[WizardStan]

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.

 

[Caine]

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