This would be a good project. If the pi-top runs headless then would save even more battery as it will boot faster and not have to load the gui and can under clock the cpu and save even more battery life.
What my understanding would be is, run the pico to take sensor readings like every 10-15 mins and after 24 hours send a signal to the pi-top to turn on. The pitop runs a script on boot to take an image, transfer the data from the pico and whatever else then sleeps. Rinse and repeat.
Yeah exactly. That’s one option, the other is if you are interested in a specific event you can turn it on when that event occurs - for example maybe if the ultrasonic sensor detects an animal you could wake up the pi-top to take a picture. Might have to be a pretty slow-moving animal though depending on boot speed 
I need to explore this idea further, think it would be an interesting project to undertake. Can also make a housing so the pico interface plate and sensors sits nicely to the bottom of the pitop
@CAProjects and @duwudi: thanks, the strange thing I noticed is that when the universal pcb is connected gps no longer works.
With a fresh build and the universal pcb not connected the gps works. Once I connect the universal pcb I get the following output when running cat /dev/ttyS0.
And bind issues
My gps unit is connected to the pitop gpios.
The usb on the universal pcb is connected to a wifi card and works without issues.
It’s just this behaviour of the gps connected to the gpios that is confusing me to think this additional usb on the universal pcb is using serial.
Any suggestions or help is more than welcome as I would very much want to use the Gps on the gpio and make use of the additional usb port on the universal PCB
Hey @Luis… I love how that little device is looking now, it looks so badass!
It’s very odd that the UI PCB is affecting your GPS though, it definitely shouldn’t be! As Ryan and CAProjects have said, the USB on the UI PCB is just running straight from the USB hub inside the pi-top, which connects directly to the raspberry pi, so there’s no USB-to-UART or anything like that. The rest of the board is basically just a breakout board, with little or no electronics on it. I’ve double checked my schematic and the UART pins (GPIO 14 & 15) are only connected to the pads on the 40 pin headers (the solder pads, and the bottom-entry header). Could there be some kind of electrical short on your board that’s interfering with pins 14 or 15? If this were a higher baud rate / frequency I might also have suggested that the added electrical ‘stub’ that’s created by adding the board could be creating high-speed signal reflection problems, but this can’t be a problem for such low frequencies.
I have a solar charger designed for the pi-top on the board of projects to build… was going to wait to say anything until my other projects here are complete, but might as well throw it out now since they’re getting close.
Any chance we can get the vin file for the micro controller? And just a pinout on which pads are what and needed for flashing? 
Hey @CAProjects!
Yep that’s right, the MCU will need to be flashed with the firmware in order for the analogue ports to be used. If you do happen to have a JLink programmer or Holtek programmer, I could provide the BIN file and some instructions for you to do it yourself (incidentally, that’s what those headers you mention are for - just MCU programming headers! The labels are my idea of a little joke to my fellow hardware hackers 
)
And yep, an annotated image of the UI PCB sounds sensible, I’ll put that together ASAP! I think a little ‘fact page’ would be useful actually. I’ll get to work on that.
Edit: just seen @Supernovali’s comment too - I’ll create a page with the BIN file, schematic and a labeled image, seems like it’ll come in handy!
The garble your getting is gps data just wrong. Check that the baud rate set matches your device. That’s normally the main cause by default the raspberry pi is set to 11250 or something like that. My script sets the baudrate to 9600 just for the script.
Try this command
stty -F /dev/ttyUSB0
Then
stty -F /dev/ttyUSB0 to make sure it’s set of not run the previous command again
Then sudo cat /dev/ttyUSB0 9600
@wil I don’t have any of those programmers so no worries, I totally understood that it was a prototype so that means something may not work and I laughed at the text, found it quite funny
@wil: Hi, thanks a lot for the reply and reconfirming, I will need to have a careful look into this during the weekend, I just wanted to rule out the usb-to-uart. I simply love the board and if I can’t find a solution with the current setup, I might go down the route of using the gps via usb, it wouldn’t look so packed together but it is what it is😂. Thanks again for the fantastic work with this board,it just opens up so so many possibilities.
@CAProjects, thanks for looking into this. The baudrate doesn’t seem to be the issue, I have tried before to add the baudrate in config.txt. Have also run the code you suggested and I am getting the following:
Guys, I found the problem, it seems the overclock I did a was culprit. Once I went back to the defaults everything is working. 
. Now both gps and wifi adapter are working.
That’s very curious… what were you overclocked to? Generally, overclocks shouldnt change board rate as the timers are set by hardware. The raspberry pi knows that its counting faster than it was before.
@duwudi bug report possibly?
I was running arm_freq=2000, gpu_freq=600 and over_voltage=6. For the overclock I was a bit lazy and did it with commanderpi. Don’t know if this matters. But I went back in /boot/config.txt and uncommented these lines and gps was working again. It was driving me crazy since I did not know what was going on. My fault here was that, again was very lazy😂, copied the config.txt since I didn’t want to put everything in for the new build and connected the bottom plate. This lead me to believe in error that the universal pcb has something to do with it, when all along it was the OC.
Hey, if it works, roll with it! Overclocking is pretty simple on the pi though… I’ll test the baud rate in a little while and see if I have issues too. I’m currently running 2200 cpu and 725 gpu with +8 on voltage. Now I’m curious haha
@Supernovali: Hahahaha, you went pretty much full speed with those😂. Would be interesting to see if your setup is doing the same. Pls post the output of cat/dev/ttyS0 to see if you get those funny looking characters😁.
@Luis do this
apply the over lock and add core_freq=250 to /boot/config.txt
No big report needed I completely forgot about what I mentioned above. If you google gps and raspberry pi it’s always said to add the line above. Wasn’t till @Luis mentioned overclock I remembered core_freq setting
Okay folks - I’ll host this as a PDF somewhere sensible soon, but as a sneak-preview here’s the full schematic of the UI PCB. To my knowledge this is the first time we’ve shared one of our internal schematics - brave new world! But a very exciting one too, open source is definitely the way to go. Let me know if you spot any problems - annotated board image to follow soon too!
Oh hahaha yeah, core frequency might do it haha
And @wil, very nice and clean schematic! I love it! What program are you using to generate this? Looks better than KiCad
OrCAD Capture and Allegro are our schematic/layout weapons of choice at pi-top 