<Xogium>
ok navit blows up here as well, and I have no damn clue why
<Xogium>
stupid piece of crap
sc6502 has joined #Speedsaver
<sc6502>
Morning, long time no speak.
<Xogium>
oooh hello Steve :)
<Xogium>
how have you been ?
<sc6502>
Well, but very busy, and you?
<Xogium>
about the same, especially this morning, trying to figure what happened
<Xogium>
which I did but yeah, breaking changes in a lts release. Bad
<sc6502>
So I hear from Peter.
<Xogium>
yeah so… What happened is, gpsd needed to add a leap second before october 24 2021
<Xogium>
I assume you know what those are ?
<sc6502>
I know about leap seconds, yes.
<Xogium>
anyway they did so, which is good, the problem is this was non trivial to backport to 3.20 which was until 2021.02.7 of buildroot the version we used, as per the lts
<Xogium>
gpsd folks decided to simply not backport it
<Xogium>
so buildroot had no other choice but to bump gpsd knowing full well it could introduce potentially breaking changes… Which it did
<Xogium>
Move gps_data_t->status to gps_fix_t.status for better fix merging
<Xogium>
and navit blows up when compiling because of this
<Xogium>
let me find it again in case you don't have the error
peterm6881 has joined #Speedsaver
<sc6502>
Will it show up if I sync to latest?
<peterm6881>
hey roomies
<sc6502>
morning :)
<Xogium>
2021-11-14T01:45:24 vehicle_gpsd.c: In function ‘vehicle_gpsd_callback’:
<Xogium>
2021-11-14T01:45:24 vehicle_gpsd.c:161:28: error: ‘struct gps_data_t’ has no member named ‘status’
<Xogium>
yes it will show up if you sync to latest external tree and use buildroot 2021.02.7
<Xogium>
hey peterm6881
<sc6502>
OK, I'll do that.
sc6502 has quit [Remote host closed the connection]
sc6502 has joined #Speedsaver
<peterm6881>
wb sc6502 :)
<Xogium>
might need a full rebuild to see it
<sc6502>
Meh, what!? suddenly quit for no obvious reason.
<Xogium>
wah ?
<Xogium>
weird
<peterm6881>
i thought it was something I said ;)
<Xogium>
hehe
<sc6502>
On https://buildroot.org/download.html how do I find buildroot's public PGP key? Having signatures is fine, but meaningless if I can't verify them.
<Speedsaver>
Title: Buildroot - Making Embedded Linux Easy (at buildroot.org)
<Xogium>
don't they provide that ?
<Xogium>
I admit I never bother checking gpg
<sc6502>
Not in any obvious place I could find.
<sc6502>
But they're on another IRC network now aren't they?
<Xogium>
yeah will ask them
<Xogium>
they are on oftc
<Xogium>
since freenode exploded
<sc6502>
Cheers!
<Xogium>
ok I've asked them, waiting for reply
<peterm6881>
Guys I cant decide, can I get your opinion on something. Should we throw Speedsaver onto the market based on the OPi0 initially, on the understanding we will work on our own platform, or wait and develop the platform first
<peterm6881>
Ive been reluctant to ask for funding for tooling for something thats only a stop gap, and hardware that wont shake up the market
<peterm6881>
However there are some serious players in the 3D printing market now
<Xogium>
opi 0 looks like a bit of a joke to me not to mention that now they had to switch to h3 SoC due to chip shortage
<Xogium>
besides what's the point of crowdfunding for a board we will end up discarding ?
<peterm6881>
yeah plus the price jumped from 12 USD to 18 USD
<sc6502>
What's the performance of 3D printing now? Sure injection moulding has a large up-front cost, to make 1000's per hour at the cost of pennies per unit. But are there 3D print providers that can do reasonable turnaround on say 50 units a day?
<Xogium>
people will pay for that and then get it, with no way to update their mapas or anything, because we will end up dropping it along the way
<Xogium>
*maps
<Xogium>
yup guessing they had to bump up the cost due to the fact h3 SoC costs more than h2+
<peterm6881>
its viable to get usable enclosures without the up front tooling costs
<peterm6881>
if you had to decide Xogium , what way would you jump? Wait, or throw something out there to see what happens
<Xogium>
well I'd honestly pause and consider the fact that throwing it out there too soon could take out the entire credibility of the project
<Xogium>
I mean, think about it
<Xogium>
we have no plan to continue using linux, the cost of the opi 0 increased, we don't have ways to update the maps, we don't even have new maps for that matter, HERE is a joke, xunlong is also a joke from what you told me wanting you to sign some papers for export or some such, we don't have a website for people to consult
<Xogium>
not to mention we're not even sure what we'll do on the mcu side yet
<peterm6881>
Just to play devils advocate, im relaxed about continuing to use Linux, the knwoledge is more likely to be useful for diversification into other use-cases, however a switch to an MCU would rule out linux. Im confident we could implement rauc updating ina matter of weeks and we would have up to a year to do it. We can buy maps any time, just no point till we decide to launch. We've proved HERE can make amendments based on user
<peterm6881>
input, im confident we can formalise that. To be fair to Xunlong, the Speedsavers in my car and especially in my van, which does about 30,000 miles a year, are rock solid
<peterm6881>
knowledge
<peterm6881>
There are two ways to view a launch
<peterm6881>
1: to get the snowball rolling
<peterm6881>
2: A big bang with your product as perfect as it can possibly be
<peterm6881>
so the question is do we get the ball rolling with something we know works, or wait n time for something better
<peterm6881>
deciding to chuck something onto the market can be a catalyst for sorting out the online presence. I did take steps to start developing the website, but like so many things it got parked
<peterm6881>
I have the domain and the hosting in place, it just needs built
<peterm6881>
if I throw some cash at it could have something up and running in a couple of weeks
<peterm6881>
so, all that said, would wait be your vote?
<peterm6881>
I think it should be a team decision
<Xogium>
well I dunno
<Xogium>
I'm just the embedded linux person
<peterm6881>
and resident genius
<Xogium>
sc6502: the pgp signatures files are pgp signed messages… Whatever that means
<Xogium>
12:12 < y_morin> Xogium: Basically, they contain: the md5 adn sha1 hash of a release, and the URL wehere to get the public key that signed the message, and then the PGP signature of all that.
<sc6502>
Ah thanks :)
<sc6502>
That makes sense now - I never bothered to look in the file, I just assumed it was a detached signature of the archive.
<Xogium>
yeah me too the link's not very… obvious
<sc6502>
Woohoo - build failed as described :) Now for fixing.
<Xogium>
yep I think it's not that hard to fix, probably even a single line fix
<Xogium>
but once we do that, we won't be able to go backward in the br release only forward
<peterm6881>
lol hooray for consistent failure ;)
<peterm6881>
I still have the working image
<peterm6881>
cant see us ever wanting to go backwards, but point taken
<peterm6881>
Xogium, could you outline what you found out about expanding memory on the RP2040 using swap space via the SPI interface?
<Xogium>
ah yeah
<Xogium>
its not swap space, but the idea is that one random guy on the rpi forum came up with a workaround to the fact the rp2040 has no memory mapped flash
<Xogium>
his workaround however is primitive as things are
<Xogium>
he basically grab a portion of the spi flash, mark it as invalid memory, when the cpu then hits this, he traps the signal, and tells it to use the assigned flash
<Xogium>
this is frankly disgusting and has some major overhead inplications like the fact every ram transaction now gets trapped, and every transaction now requires going through the slow spi
<Xogium>
part of what's been baffling me with the rp2040 is the lack of memory mapped flash
<Xogium>
even the most basic stm32 mcu has this
<Xogium>
for example here I work on the stm32f769 and it definitely has memory mapping for part of its flash, or even external flash
<Xogium>
in fact that's the only thing that made it possible for me to use espeak
<Speedsaver>
master @ Speedsaver: xogium ef271c: packages/navit: bump to version 81714d7ecdcc392f73c613f42d3acf0d02b5f7ad. (https://git.io/J1Jg0)
<sc6502>
Yeah, this one is now pretty old by modern standards.
<Xogium>
there we go
<sc6502>
hey peterm6881 , lunch is served :)
<Xogium>
hehe
<Xogium>
so what do you think about what I described earlier about memory maps not being a thing on rp2040 ?
<Xogium>
makes ya wonder how they even managed to pull that off and more importantly WHY
<peterm6881>
fantastic work people, thank you
<peterm6881>
Xogium, should we make that a release?
<Xogium>
well, we could
<peterm6881>
yeah if you dont mind
<Xogium>
you got it
<sc6502>
better give a quick test peterm6881 . Just to make sure the GPS didn't also mess up the meaning of status, as well as the location.
<peterm6881>
will do, i'll do a pull now
<peterm6881>
building takes about 15-20 mins in this machine :(
<Xogium>
oww true didn't think of that
<peterm6881>
ok ive kicked it off :)
<peterm6881>
sc6502, whats your view on what I was saying earlier about throwing something on the market to see what happens?
<peterm6881>
Xogium, im sentimental about all the work we've done :), and that includes John and Pierre. Its fantastic that thanks to you and Steves help, we can finally even THINK about offering this to the public
<Xogium>
we do try at least
<peterm6881>
Christmas is coming up...
<Xogium>
hmm
<peterm6881>
lol
<Xogium>
yeah, seems that way
<Xogium>
I usually don't like christmas, too much noise lol
<sc6502>
I'm generally in favour of some kind of small release just to see how it goes. Any improved hardware (and especially rewritten s/w) is many months away even in ideal circumstances.
<Xogium>
but now that I'm no longet obligated to attending parties I don't like to go to, it's better
<peterm6881>
sc6502, thanks.
<peterm6881>
Xogium, abstain, approve or disapprove?
<Xogium>
heh heh 2 against one it looks like. I guess we release it
<peterm6881>
actually im annoyingly on the fence :)
<peterm6881>
or in limbo
<peterm6881>
so could be heading for stalemate!
<Xogium>
that sounds like a bad option all around
<Xogium>
many pros and cons on both sides, but not acting is all cons
<sc6502>
:( it doesn't boot
<peterm6881>
I'd need to price it up again, professional 3d printing and the hike from Xunlong are gonna make it more expensive
<Xogium>
oww really ?
<peterm6881>
sc6502, let me try mine just to confirm
<sc6502>
There's a bit of the usual speaker crackle at the start, but then nothing.
<peterm6881>
still building
<Xogium>
could it be one of these weird issues with the board you got that randomly bugs ? I seem to recall you had this… Or maybe bad micro sd ?
<Xogium>
even the display is blank ?
<sc6502>
No display, no music.
<Xogium>
ermf that sounds bad
<sc6502>
Same result in both boxes.
<sc6502>
Going to try burning the other SD card now.
<Xogium>
ah forgot you had 2 opi not one
<peterm6881>
sc6502, did you remember to copy the maps this time ;)
<sc6502>
I need to do a bit more organising. All the USB and serial port stuff is still on the old machine.
<sc6502>
Yes, the maps are there.
<peterm6881>
unrelated to your current problem, just sayin
<Xogium>
if it doesn't work even then I'd check the status of the system over serial
<Xogium>
like systemctl status, systemctl --failed
<peterm6881>
ok build success, now to feel the burn
<Xogium>
bwahahahah
<peterm6881>
sc6502, the problem is at your end, fix and new BR works perfectly
<peterm6881>
im happy to report
<sc6502>
OK!
<Xogium>
well… at least that :S
<peterm6881>
kernel 5.15.2, nice. thank you Xogium
<Xogium>
no problem
<peterm6881>
let me fire up GOTTA_GO_FAST
<peterm6881>
never gets old :)
<peterm6881>
yup everything is working 100%, audio and gps
<peterm6881>
Xogium, id say go ahead and mark this as a release, if thats ok
<peterm6881>
we'll go with this
<Xogium>
what about the new gps you had ?
<peterm6881>
yeah let me check that, different board, hang on
<Xogium>
we need to figure out on what serial port it is
<Xogium>
like what serial port name it has
<peterm6881>
its S1 but i can change it manually
<Xogium>
how do you know ?
<peterm6881>
ttyS0 is the dedicated debug port
<Xogium>
I can modify our default gpsd config for that maybe hmm… Maybe have it use both gps
<peterm6881>
wanna give it a go?
<Xogium>
that way it would use the dongle for those that don't have the newer gps hat
<peterm6881>
ive never tried to edit it to use both, would that work?
<Xogium>
let me see how that was done again
<peterm6881>
"/etc/default/gpsd
<peterm6881>
currently set to ttyACM0
<peterm6881>
although I know Pierre tweaked the code so it can use an external gps automatically without modifying, and sc6502 further enhanced it to better prioritise, from memory
<Xogium>
yeah I just wonder if devices should be added with a space or with ,
<Xogium>
well I guess you could try and unplug your dongle and see what happens
<Xogium>
also… I just had a flash
<peterm6881>
one thing we never tried was switching between serial gps and ACM type devices
<Xogium>
do you remember when we worked on making the log print only one line out of 2 because they were indentical ?
<Xogium>
er identical
<Xogium>
I think it printed that, because you had not one but 2 gps active
<Xogium>
gpsd detected 2 gps, and so it logged the output of both
<peterm6881>
besides, the new HAT has no audio, but I have enough USB dongles I can butcher and existing HATs to do a mini launch
<peterm6881>
that does ring a bell!
<Xogium>
can you try if you remove your dongle and see if it works ok, logs and all ?
<peterm6881>
switching to the S1 HAT you mean?
<Xogium>
yeah
<peterm6881>
ok hang on
<Xogium>
without modifying the gpsd config or anything
<Xogium>
hmmm looks like we shouldn't even need that file… Buildroot has a config option to let us set gps devices
<Xogium>
I wonder why that is there
<peterm6881>
interesting
<peterm6881>
no its only reading the usb dongle
<peterm6881>
let me try editing the config file
<peterm6881>
DEVICES="/dev/ttyACM0"
<peterm6881>
what do you suggest we should change it to
<Xogium>
try /dev/ttyS1 first, then try and combine both, with a space in between
<peterm6881>
I know S1 works, I used it to test the HAT
<peterm6881>
so let me add it now
<Xogium>
I'm gonna try and get rid of that file and just use buildroot to do it instead. That should also work
<peterm6881>
DEVICES="/dev/ttyACM0 /dev/ttyS1"
<peterm6881>
like this?
<peterm6881>
yeah its using both
<peterm6881>
coolness
<Xogium>
hmm nice
<peterm6881>
I think we should have that, agreed?
<Xogium>
what does it do when ttyACM0 isn't there, back to ttyS1 ? How do we know for sure that it uses ttyS1 or ttyACM0 ?
<peterm6881>
when its using both, you can see it switching between 2 slightly different locations constantly at 0.5s intervals
<peterm6881>
whe I unplug the dongle, it settles to the HAT
<peterm6881>
replug the USB, and after a few seconds it starts flashing both again
<Xogium>
hmm
<Xogium>
is it a problem that it can litterally use 2 gps at once ?
<Xogium>
like would it be a problem with the readings ?
<Xogium>
hmm looks like that buildroot setting doesn't work with the init system we chose. Probably why I went and manually wrote that gpsd file
<peterm6881>
it would if both had a fix
<peterm6881>
but the point of the external gps dongle is so you could theoretically hide the device
<Xogium>
so what then… Its a problem ?
<peterm6881>
no i cant see it being a problem
<Xogium>
well both gps will have a fix, presumably
<peterm6881>
whether its the OPi0 or our own board, it will definitely be natively serial connection for the GPS
<peterm6881>
no if the box is hidden and doesnt have a sky view, the onboard gps will never achieve a fix
<peterm6881>
so I think we should go with ACM0 and S1 in the gpsd config file
<Xogium>
hmm
<Xogium>
sounds fair
<Xogium>
let me add this then
<peterm6881>
the only reason we're currently set to ACM0 is because I'm cannibalising USB GPS dongles and soldering them onto a HAT :)
<Xogium>
so like this ?
<peterm6881>
which actually functions extremely well but is far from ideal :)
<Xogium>
DEVICES="/dev/ttyACM0 /dev/ttyS1"
<peterm6881>
yes, although I put S1 first, simply because its the native connection on the new HAT
<Xogium>
ah yeah good idea
<peterm6881>
I checked and JLC have put the audio chip in the correct orientation, so I've asked my board designer whay else there might be no audio
<peterm6881>
lets see if we cant turn this into cash
<Xogium>
hmm
<Xogium>
this looks fun
<Xogium>
some lab mamanged to encode a video, an audio clip, a document and a picture in a bit of DNA, sent it over to the other side of the world and they managed to decode it back
<Xogium>
*managed
<peterm6881>
jeepers
peterm6881 has quit [Remote host closed the connection]