Introductions - Who are you, and what are you building with UNA?

Getting Started
1

Nice to have you onboard!

It would be great for you to tell us who you are and what you’re planning to build with UNA!

4 Likes
2

Hi all, I’m Lewis, founder of UNA. I’m an Electronics Engineer by background. I’m hugely intrigued to see what ideas developers come up with!

3 Likes
3

Hi everyone! I’m Ed and I’m part of the team here at UNA. Looking forward to seeing what everyone gets up to using our SDK

4 Likes
4

Hi there :hand_with_fingers_splayed: I’m the frontend developer responsible for the mobile and web applications

4 Likes
5

Hi everyone.

I’m Ross - A firmware developer at UNA, working on the watch firmware and official apps.

I’m also an amateur runner, doing road races from 5k to half marathon.

5 Likes
6

Hi everyone!

I’m Rafał, and at UNA I’m responsible for the technical side of the mobile app, backend, and cloud infrastructure.

Excited to be here and to help build the platform behind it!

Cute Dog Says Hello

6 Likes
7

Hello! I’m not associated with UNA, I’m a software developer in Eastern Ontario, Canada. I spent a bunch of time working with the SDK to make sure it ran on Linux before receiving the watch, and since then have been trying to build one of everything just to see what works.

I’m rocking a Garmin Fenix 6 Pro and trying very hard to displace it with the UNA. In terms of stuff I’ve been experimenting with:

  • I have local raster maps for GPS enabled activities
  • vector maps kind of working, but need more preprocessing to strip out features so they don’t suck
  • I have a sleep detection PoC that I’m trying to prove out by sleeping as hard as I can
  • a very early days racquet sport app trying to gather data to see what can actually be gleaned (rally length, forehand vs. backhand ratio)
  • GUI PoC written in Rust (on Linux, TouchGFX is a barrier and I’m a Rust addict)
  • I’ve been trying to upstream as much as possible

Extremely excited to finally have a high quality programmable GPS watch, this is a product space I’ve been keen on for years.

10 Likes
8

Truly awesome to hear how much you’ve developed in such a short space of time! Thanks for joining the forum.

2 Likes
9

Hey folks!

Great to have a forum to meet other people building fun stuff :slight_smile:

I’m Juhani, not associated with UNA either. Just an interested geek playing with code.

I’ve been experimenting with trail running feartures for UNA. A small blog post on that here:

Outside UNA I’ve been building some trail running specific software for trail runners here: https://vertmatch.run/

I’m really positive abotu what the watch is capable and hopefully we can build a nice nerd-community around it as well!

3 Likes
10

Great to see what you’ve been building Juhani!

2 Likes
11

Hi everyone,

I’m LilMouse (Anne). I’m not with UNA either but have been looking forward to getting started with the SDK and making apps for a while now.

Going to set up the environment this weekend and it is great to have a place to ask questions and share my progress.
I am an embedded software programmer and usually program in C but have also been experimenting with Rust. So I am curious to see what I can do there :grinning_face:

My first plan is to get an activity minutes/step streak going in the watch.
Then get started on a couch to 5K trainer. That will be a little more work since it has nested intervals.

After that I plan to gamify my movement and workouts more. I have a minor in game design and would love to apply that to movement based games. Though I haven’t done much with it before, the UNA watch is perfect for it I think.

5 Likes
12

Hi Anne, that all sounds awesome! Can’t wait to see the progress!

1 Like
13

Rust GUI sounds extremely interesting. Any chance you’re publishing that somewhere?

14

Hi, I’m Julian, I used to be a developer, but have had a career change. I’ve been excited to do some Una programming. So far I have a Parkrun barcode Glance, working every week for my scans, an OS Grid reference Glance, so you can see where you are, and ICE glance, and a GPS diagnostic glance. On the activity front I have done a very simple yoga activity, and a much more ambitious and versatile activity, that can be configured either for walking or running, with a dog or without, and also specifically canicross, and more importantly, will show you your OS Grid reference, and also show a calibrated altitude, to overcome the shortfalls of both GPS altitude and barometrically derived altitude. This is working extremely well. I am planning on internationalising it so it can work elsewhere in the world. I’m looking forward to being able to release some of these features!

3 Likes
15

Hi everyone. Although I’ve been in tech for decades, I would definitely not call myself a developer, so please accept my apologies in advance for any sins that I may commit… :wink:

That said, UNA is part of my ongoing divorce from the tech bros, so I’m really keen to see what we can achieve with UNA Watch!

1 Like
16

Late to this thread, but your Linux work is the reason I have anything running at all, so thank you, and I would like to offer something back.

My machine is ARM64 (WSL2 on Windows on ARM), which the Linux path does not quite reach. The vendored TouchGFX Linux libraries are x86-64 only and the framework core ships as binary objects, so there is no native build. I ended up running the simulator and the ARM firmware build in amd64 Docker containers under QEMU. It works, and the emulated build of Waypoint came out byte identical to UNA’s CI artifact apart from the version field and CRC, but it is slow, and two things bite:

  • QEMU cannot run x86-64 Ruby, so textconvert and videoconvert die. Since every project commits its generated/ output, a guarded shim that asserts the committed files exist gets past it, at the cost of not being able to regenerate text or fonts locally at all.
  • The same QEMU issue breaks python3-full’s postinst, which is why I install just python3-pip rather than following apps-ci.yml exactly.

Which brings me to the offer. I noticed your fix(cmake): make builds independent of where the SDK and app are checked out and the CI job asserting an app builds identically from two directories. I kept my app outside the SDK checkout and can confirm the CMake side holds up: it built first time with no path changes. The simulator side is still fixed depth, though, and I had to patch each of these by hand:

  1. config/gcc/app.mk, where touchgfx_path goes six levels up
  2. config/msvs/Application.props, where TouchGFXReleasePath goes eight levels up
  3. the mock filesystem sandbox, five levels up plus /Output, which silently sends AppConfig to the wrong directory and falls back to defaults
  4. simulator/gcc/Makefile and the .vcxproj do not glob, so a new .cpp links fine as firmware and fails only in the simulator

I would be glad to put a PR together extending your two directory CI assertion to the simulator build, if that is a direction you think would be accepted. I could also add a short note to Simulator.md along the lines of “ARM64 hosts: use the Windows simulator or an amd64 container, and here is why”. The first symptom is a thoroughly misleading imageconvert.out: 1: Syntax error: "(" unexpected, which is really ENOEXEC, and it cost me a while to work out.

One question, since you have built one of everything: have you run into std::localtime() returning UTC? I have posted about it separately. And I am curious about the Rust GUI PoC. For me TouchGFX is not only an authoring barrier, it is the specific reason I cannot build natively at all. A non TouchGFX GUI path would turn my emulated loop into a native one, so I would be interested in how far you got.

1 Like
17

Rust GUI sounds extremely interesting. Any chance you’re publishing that somewhere?

…

I am curious about the Rust GUI PoC

I’ll start another topic for this rather than make noise here. Prepare to be underwhelmed though, it’s truly a PoC and all it does is paint the screen. It’s C++ right up to the designed CustomGUI/main.cpp, so it’s (I think) how any non C++ would integrate.

Edit: Populating the GUI framebuffer with Rust

18

I’m sure I’ll be whelmed, whether it’s under or over is still to be seen… :wink:

Will take a look at your new post, and thanks for sharing!