Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - DDR

Pages: [1] 2 3 ... 7
Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: October 17, 2018, 09:28:32 PM »
Hi SamL. I'm not sure when the HTTP API will be released. However, for you and everyone else curious, an explanation is is order.

Here is a map of the tasks we're working on. (Click for larger version, or see attachment 1.)

Green = done
Yellow = in progress
White = not started

The blue circles denote areas we're actively working on. In order:

One of our engineers, Johan, is implementing the underlying D-Bus API right now. The HTTP API (not pictured) will act as a wrapper for the D-Bus API, so as the timing works out, when the D-Bus API is done the HTTP API should be done as well. Johan has so far implemented reading the power controller for battery charge, and is currently porting reading/writing to our FPGA. Soon, we can do actual useful stuff with the API, but how soon is unknown. Johan hasn't done this before, and therefore can't produce an accurate estimate. I'm guessing it will take him at least few months to work through everything. Assuming we can get out some sort of gimped HTTP API built on that work, which won't run simultaneously with the touch-screen user interface on the camera, I would very roughly estimate "late January" for basic HTTP control. This should not include video streaming, but should include video download and basic file management.

I am continuing work on the new back-of-camera user interface. I've spent the last two weeks working on one of the two great unknowns of the process, jog wheel input. The other great unknown, the software keyboards, I will start work on tomorrow. I don't know how long the software keyboards will take. They could take a few days, or they could take a few weeks. The jog wheel still needs roughly a week or two of work, as each widget needs its own behaviour implemented. (Menus are going to become a heck of a lot easier to select. :D)

Foobar has effectively ported the current UI forward to our shiny new Debian-based operating system. This is a major milestone for us! It means we can abandon our old operating system, which was sucking up a lot of our time. It also means we can do a more piece-wise release of the new features as they're built out, so we may see useful parts of the HTTP API available well before the full HTTP API is finished.

Software Dev / Re: Updating the UI: Network / Remote Control Screen
« on: October 05, 2018, 04:03:39 PM »
ARIN says they're reserved for private use. I'm not sure what the implications are, though.

Quote from: ARIN link=
Note that only a portion of the "172" and the "192" address ranges are designated for private use. The remaining addresses are "public," and routable on the global Internet.

I figure it'll be fine in most cases - anyone setting up a nonconforming network either knows what they're doing or have larger security issues.

Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: October 02, 2018, 08:21:44 PM »
I also wonder if a recording and saving in 8 bits (corresponding to low light) could be an option in the future ?
It is hurting saving all the nonessential data, isn't it? :( We do like the idea of saving at a reduced bit depth, but it would be a fairly far future thing if we did it. Unfortunately, there are several other things that need our attention first. Motion triggering, (most of the) text overlay, power control, etc.

That's why an increasingly high number of devices just use HTML/CSS/JS for their UI and slap a basic webengine on there to display it. not as fast as natively coded ui's but allso much less hassle and the same tech on all platforms.
I was considering that, actually, but rejected it for performance reasons. Even the new native app I'm working on is having trouble rendering at a decent framerate right now. It's usable, but it's not ~buttery smooth~ like the old one is. Since most of it isn't my code, and I haven't done anything obviously wrong, it seems like it's some combination of the new libraries, the upgraded framework, and the easier-to-touch styling. :-\

Software Dev / Re: Updating the UI: Network / Remote Control Screen
« on: October 02, 2018, 07:48:35 PM »
How are you actually checking that the connected interface is "just" LAN? I'm not too familiar with "advanced" network setups...
For SSH, we can restrict logons to the 192.168.x.x subnet. This subnet is not publicly routable, so it isn't accessible from the internet at large.

Will there be an additional screen to manage certs or will whe have to set them up using the WebApp/ SSH?
I think you'll have to accept a self-signed certificate. Certs are very much tied to domain names, and since the camera doesn't have a domain name it can't really be certified as being "at that domain". The whole HTTPS system falls down a bit for embedded software, unfortunately. :-\

And one very minor nit-picky detail: the port is set to 22 but the command shows 22786 :P
Oh shoot! Totally missed that one. xD

I prefer the v4 because the only difference seems to be the text
I moved the interface up into the header, since it selects what information is shown too. But yeah, not too much difference between the two.

Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: September 27, 2018, 08:29:32 PM »
0.3.1 still not out……
There were... issues. 😒 In fact, there still are issues, but those will be fixed soon. Foobar's fixed a DNG import issue… as of 7 minutes ago now, we think. (It's still got to be tested though. From what I've heard around the office, it should be possible to imperfectly fix the DNG files recorded with the current beta. We haven't tried, though, so take this with a grain of salt.)

This sort of delay is why we try to avoid saying we'll do things. We're very wrong, very often, and it is never in the direction of "sooner". 😭

On that note, I myself am trying to get the jog wheel to work with *absolutely everything*. If I can get this working as I'd like, we'll be able to do stuff like use the camera with mittens on during cold weather.  I'm currently trying to figure out how to read from the FIFO file which reports jog wheel position, and then how to interpret that to a rotation, and how to get THAT into a reasonable event in the QT framework… and then I need to actually make the widgets behave correctly. It's a surprisingly long road, I've been at this particular task a few days now.

I miss the web. It would have been onscroll="whatever()" there. But of course, the web has other issues. 😜

Chronos User Discussion / Re: Moonlit stills, Chronos suitable?
« on: September 27, 2018, 08:16:23 PM »
From what I've heard — and this is second-hand, since I've been dealing mostly with the user-interface software here rather than the hardware — the sensor in the Chronos is a bit weird. The longer the exposure time, the noisier the results from the sensor. IIRC, after half a minute of exposure the resulting picture is effectively gone. Something in the physics of it accumulates errors over time, rather than averaging them out like in a normal sensor.

Software Dev / Re: Chronos V0.3.1 Beta
« on: September 27, 2018, 08:01:04 PM »
I think it should be a matter of adding some tags to the non-loading files. We've figured out what tags are needed, but we're still getting things sorted here. Sorry about that!

Software Dev / Re: Updating the UI: Network / Remote Control Screen
« on: September 27, 2018, 06:27:56 PM »
wouldn't the "enable network interface" checkbox make sense as very first item since everything else depends on it? maybe grey out all the features not working if the net is disabled. Also, does not enabling the network interface still leave the possibillity to connect via USB? If so that should be mentioned somewhere, preferably in the manual ;D

Hm, this is actually a fairly deep question now that I look in to it. After talking it over with my colleagues, we've decided the problem is not as neat as I'd initially thought.

We figure that connecting via the microusb cable is a special case. Since you have to be physically present for this, you always get access to SSH and the remote control app this way. You connect your computer to the camera via USB, visit the URL it says to, and it should "just work". SSH will ask for a password, but the remote control app will not. This is non-configurable, and will always work, and will definitely be mentioned in the manual. :)

If you plug in ethernet or (hopefully!) a wifi dongle, the camera will be accessible over the local network at 192.168.*.*. If you access the app this way, it will ask for a password. SSH still asks for a password as well.

If you go into the settings and check the Enable Remote HTTPS/SSH Access boxes, you can access your camera from anywhere on the internet. (Provided you can route to it.) However, since everyone on the internet can now route to your camera, this is left off by default. HTTPS will be supplied by a self-signed certificate, which you'll have to click through a warning to accept. However, I don't think there's actually any other way for us issue a cert for a device-hosted web app, and I definitely don't want to expose the camera control through non-secure HTTP the internet at large. :-\

Since the default is now to *not* allow SSH from the internet, I'm comfortable with simply setting a password for SSH. You should still use key-based authentication for SSH if you allow access from the wider internet, but you can turn that on from the command-line.

To that end, I've mocked up two new variants of the screen.

Version 4:

Version 5:

Software Dev / Re: Updating the UI: Network / Remote Control Screen
« on: September 26, 2018, 06:56:05 PM »
Thank you for the feedback, NiNeff and BiduleOhm. I've spent a few hours here going back and redesigning the screen, and it has really benefited. :D

Version 3:

Of course it should not be the only element in your security, it's just a very simple way to avoid the majority of attacks.
Exactly, BiduleOhm.

It might also break (badly designed) stuff which relies on the defaults. I do however like the general idea to be able to change the port using the UI.
I've never come across anything that's been unable to deal with nonstandard SSH ports either, since it's so common. However, I can definitely see some networks could be locked down in weird ways. I've added it to the design. :)

For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).
Hm, probably best to make it easy, then. Plus, I was able to add the actual command to connect in that space. :)

Indeed, get rid of the locking. It's less stuff to implement and more screenspace!
Gone! The illusion of security is worse than insecurity itself.

I also prefer version 2. However displaying 2 QR Codes next to each other is confusing and might be error-prone. Maybe only ever display one type of IP and add a button to switch? Like "display IPv6" ?
Given the relatively poor support of ipv6 overall, I've removed it from the GUI entirely. I think it would just cause confusion for the most part when it inevitably didn't work. ipv6 is still be available through the command-line interface, and it should be visible in the connected devices on your network as well.

Then perhaps call the button next interface or next adapter. I had to read your description to figure it out, but it should be obvious from just looking at the picture.
You're right. I've made a drop-down menu so you can select what network interface you're viewing. It says what you're connecting through, so you don't have to guess now. Thank you for calling me out on that. I think I did some rather bad design work there in retrospect.

Software Dev / Updating the UI: Network / Remote Control Screen
« on: September 21, 2018, 09:23:38 PM »
So, something I just realized here is that - now that we have Debian up and running - we need a way to configure network access. This covers HTTP for the web app, the HTTP control API itself, and SSH access to the root of the camera. Now, a word of warning - I'm a UI designer, not a network admin or security expert, so I'm actually somewhat unsure of this design. Please call me out on my mistakes.

For configuring access to the web interface, it wouldn't do if just anyone could log on to our cameras and control them by default. Someone might go and make a web page that gave you control of a random camera, and we wouldn't want that. I figure requiring a password to be set before enabling web control will avoid that problem nicely. It's also probably all we can do anyway, since anything more, such as 2-factor authentication, is much more effort and complexity than it's worth in this scenario. We may not be able to use HTTPS anyway, so whatever credentials are set will somehow wind up transmitted in plain text anyway. We can hash the password, at least, but it's still fundamentally insecure. This would be all fine over a local network without access to the internet at large, but the internet has a habit of getting into places it shouldn't. :-\ Realistically… though… it would probably be fine. But still. Sheesh. I'd like to do this properly if I can.

For SSH access to a Linux machine, given the amount of malware that's out there trying to log on to everything, best practise is to use key-based authentication. We could use a password, but I think that is inviting disaster given the sheer volume of shit that will be thrown at the camera. Since anyone wanting to SSH into the camera will probably have used SSH before, and since key-based authentication is quite common, I assume it's quite reasonable to require it to access the Chronos CLI.

We could have a password and *then* let you set up key-based authentication on your own, but I think most people will honestly just set the password and get on with whatever they need to do.

Connecting via the MiniUSB would bypass all access control. Since you have physical access, you could just reprogram the camera firmware anyway, so there's no reason to deal with any of this. :D

With all this in mind, I've mocked up two versions of a network control screen.

Version 1:

In version 1, we've laid out remote control, api access, and ssh access authentication.

Tapping on one of the SSH keys in the list will highlight it and show an X, and tapping the X will delete that key so it can't be used to log on anymore. (All keys grant access to log on as the root user. This can be changed later by logging on and setting up users as you want, if you want. Since the Chronos is running a Debian Linux under the hood in this instance, you can do whatever you'd do on a traditional server. I don't really anticipate wanting to manage users though, so I've made no allowances for it in the UI.)

I've made the screen lockable, not that it's worth very much since anyone can pop out the system MicroSD card and fiddle with the saved settings on it. I might just remove the button entirely, since perhaps it confers a false sense of security.

You can also click the underlined address to bring up a QR code. I don't like typing things in, much simpler to just scan and be taken to the mobile app. ;D

Version 2:

In version 2, which I like quite a bit more, I unified the HTTP API and web app controls. The web app uses the HTTP API to control the camera, so you can't really have one without the other. I figure if you're just using the HTTP API, it's not a big deal if the web app is being served in the background. You can just ignore it. Unifying the controls also freed up enough space to display the IPv4 and IPv6 addresses' QR codes on screen, which I think is less confusing. We don't use the underline anywhere else in the back-of-camera UI.

One alternative to this layout might be to drop IPv6 address entirely () and put a longer description in that space. It would be nice to use IPv6 to expose the cameras on the internet, though, since stable IPv4 addresses are getting harder to come by these days.

Note: The web address section only shows up after you've enabled the network interface. The "Next Address" button only shows up if there's more than one active network interface - ie, you've plugged in MicroUSB and Ethernet, and maybe WiFi if we can get it working reliably. It'll cycle through the things which are plugged in.

So, as always, please tell me you think. The best time to change designs is while they're still on the drawing board. :)

Software Dev / Re: Updating the UI: Battery
« on: September 20, 2018, 07:03:27 PM »
There, fixed the labels. :D

And as Selkit pointed out, the % was displaying as a decimal instead of an integer. I also realized I forgot the "Save & Power Down" line, so I added that in too to give sort of a visual representation. Sheesh. :P

Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: September 20, 2018, 04:22:07 PM »
How is it the 0.3.1 version going? Gonna release it anytime soon?
Very soon. It's been in pre-release testing for a few days and nothing catastrophic has happened yet. We'll be able to release it today, with luck!

Where does onboard Cinema DNG Raw recording fit into this schedule?

Might be interesting to look at the new BlackMagic Raw format as a next-tier / next gen codec option.

CinemaDNG Raw recording should be in today or tomorrow, with the new release.

If I recall correctly, I think BlackMagic Raw is off the table for now. I think we can't record it without giving someone a rather large pile of cash.

Software Dev / Re: Updating the UI: Battery
« on: September 20, 2018, 01:13:33 PM »
True... where 100% voltage would be is 'camera explodes at this point', too. 🤔

I'll add voltage labels to the chart, and colour them accordingly.

Software Dev / Re: Software Roadmap - 0.3.1, 0.4.x, etc.
« on: September 18, 2018, 09:00:57 PM »
Oh, got Implementation (Front-End) → Power in today! Took me a day or two to figure out how to draw the graph, and I'm still not 100% happy with it. I'll fix it later, though. It's more important to get it working right - and in your hands - than it is to get the colours correct.

Software Dev / Re: Updating the UI: Battery
« on: September 18, 2018, 08:49:50 PM »
Figured I'd post this for general interest - I've got the battery & power screen working, ui-wise. It's running against mock data, but when this data is live it should work exactly the same way. (I still need to do the checkboxes, but that'll come later. Even the checkboxes in the design are mocks… I'm definitely going to make them more elegant. ;) )

Pages: [1] 2 3 ... 7