Mobius requests

Usually Unfocused said:
I thought about this some more yesterday. I was at a client's, and used a idle XP box to try the GUItool for both the 0.53 upgrade and fiddling; vs. editing the CONFIG file.

I realized that the biggest thing that annoyed me about the date issue is saving/loading the file back & inadvertently resetting the clock to an old value.

So my idea is this:
Make the Date line written out to flash invalid enough so it will NOT be accepted & processed when loaded, just ignored.
You have to fix it to make it valid.

This could be one of many forms:

  • Date time=[????/??/??-??:??:??];date time setting,format yyyy/mm/dd hh:mm:ss
  • Date time=[2013*06*28-21:33:34];date time setting,format yyyy/mm/dd hh:mm:ss
  • Date time=[?013/06/28-21:33:34];date time setting,format yyyy/mm/dd hh:mm:ss

and others. Assuming there's a value to have the timestamp of when the CONFIG was saved rules out the first.
But any other alteration could work.
Click to expand...
I can assure you that will most likely never be implemented. There are many more important features to implement and only very few users who edit the config file. The config file should be considered as an emergency configuration tool in case Windows or a compatible smartphone is not at hand. We should appreciate the fact that the file is available. Other systems don't have both a GUI and a file configuration possibility.
I can well imagine the config file will be dropped if the developer runs out of code space.
 
Isoprop said:
I can assure you that will most likely never be implemented.
...
I can well imagine the config file will be dropped if the developer runs out of code space.
Click to expand...

That would be an unfortunate move. The universal access it offers is valuable to many; not everyone runs Windows.

As for whether or not this idea is adopted, this thread is for suggested improvements. Not all will be implemented, but one thing is true: if no one even asks for it, it is not likely to be added.
 
We had a discussion about if the Mobius will overwrite JPG's when running in looped video mode.
I see an easy improvement that would improve the product and ensure that does not happen.

The Mobius creates a subdirectory under DCIM named 100HDDVR or such. Once, it created another one named 101HDDVR or such.
Based on some experiments I did yesterday, it appears the "delete oldest" takes place only in the active subdirectory.

But it would be trivial to have it put JPG's under a different subdirectory, such as 100JPG.

So my suggestion is:

Put the JPG's in their own subdirectory.
 
Usually Unfocused said:
That would be an unfortunate move. The universal access it offers is valuable to many; not everyone runs Windows.

As for whether or not this idea is adopted, this thread is for suggested improvements. Not all will be implemented, but one thing is true: if no one even asks for it, it is not likely to be added.
Click to expand...
Very true. However, if I were the developer I would have very mixed feelings (in the negative sense) about all the requests. IMO, some are totally out of question for the Mobius. Maybe some large organization could build the perfect (dash)camera that would suit everyone - but it would never suite everyone anyway. I agree too many requests are better than not enough, but I personally believe people are asking for features that are totally out of question. The developer has a very small team and is already weeks behind schedule. He most likely regrets he added the auto-power-on connect which is proving extremely difficult to implement in combination with other parameters. What may be considered something simple, is one of the more complex functions to implement correctly. It has to be remembered that the Mobius is designed as a universal camera and not dedicated to any specific purpose. This makes it much, much harder to implement dedicated functionality.
What you think is trivial, may not be trivial. For example, it was not possible to use a different folder for storing file names. This is a function built into the DSP. The latest library from the chip manufacturer has, however, overcome this limitation - but there are still problems which have yet to be solved. The developer does NOT have full control over the DSP as many people seem to think. In fact, there are many things that are just not possible without the help and goodwill of the chip manufacturer.
 
Isoprop said:
IMO, some are totally out of question for the Mobius.
..........
The developer does NOT have full control over the DSP as many people seem to think. In fact, there are many things that are just not possible without the help and goodwill of the chip manufacturer.
Click to expand...

Indeed. While my programming language is solder, my friends/co-experimenters sling the code on our project [with several embedded controllers] and we've often cursed discussed that product's limitations.

I agree some of the suggestions here are from left field; but midst all that chaff, there is some wheat as well. Winnowing it out does take some but not a lot.

I hope the developer takes the suggestions as enthusiastic endorsements of her/his work; that is my intent, at least.
 
Last edited:
F08 - remove the 1 second overlap between videos.
In my settings of 3 mins. video length, the Mobius is creating 5430 frames which means 03:01.000 seconds.
I made a cut of 30 frames from the previous video or 30 frames from the next video in virtualdubmod and when joining the videos which contains only one cut of 30 frames, there was no frame loss.

So is not needed to overlap the video because the chipset is not missing any frame.

When you have a nice trip and want to join the files is ugly to watch that 1 second overlap especially when in the video is also a voice recorded. Videos with overlaps or missing frames are looking not professional, childish.

Also I observed that every 14th frame is duplicated. When jumping from keyframe to keyframe in virtualdub this is made from 15 to 15 frames. This is good for editing.

enjoy,
Mtz
 
Last edited:
When writing only JPGs does it overwrite files when the card is full?
Click to expand...

I don't think so, but I'll make a test.
If nothing else, I'll check the file system file count limits.
Looks like it will take 12+ hours @ 4 /second....

Oh..the rear LED does not blink for JPG's??
 
Last edited:
Usually Unfocused said:
I don't think so, but I'll make a test.
If nothing else, I'll check the file system file count limits.
Looks like it will take 12+ hours @ 4 /second....

Oh..the rear LED does not blink for JPG's??
Click to expand...
The rear LED always blinks when taking photos except when you use time-lapse mode with a time-lapse less than 2 seconds.
Time-lapse periods less than 2 seconds require special coding and are extremely time-critical. A 'simple' blink requires a count-down timer which takes away precious processing power for functions that are not integrated in the DSP. This is also the reason that photos taken with a time-lapse less than 2 seconds will never include a timestamp. An acceptable compromise for having such short periods, IMO.
Since this question has already come up twice in the last few days I'll most likely add it to the manual in the next revision.
 
Last edited:
russ331 said:
Are revisions to the manual announced at http://www.rcgroups.com/forums/showthread.php?t=1904559 ?

Would you also please post it here? I downloaded the manual on 1st October, but don't know whether it's been revised since then.

Sent from my iPad using Tapatalk HD
Click to expand...
I don't post when a manual or software is updated in the rcgroups thread. New firmware which contains new parameters will only run with the latest GUI version, so that's a good time to update the manuals as well. The GUI is always backward compatible to all previous versions, but the manual isn't! Normally, the most up-to-date manuals are those found integrated in the GUI. The last line of every manual shows the revision date. I also always update the GUI download page with the corresponding revision date. The latest revision was made on the 15th October so your manual is outdated by a few days ;)
I'm constantly updating both the GUI and manual, for example rewording or spelling, but it's not worth the trouble to update them on the internet until there's a major change or bug correction. I had the last revision of the manual ready about a month before the corresponding firmware was released, so obviously couldn't post it on it's own. Since the manual mainly describes hardware functionality, I don't expect I'll need to make many more amendments now that we know that different lenses are available and supercaps can be used in place of batteries.
Which brings me to supercaps.
I have not yet been able to evaluate how long they last. My initial tests were done using a now extinct FW test version. The auto-start/stop functionality is currently undergoing major modification so I believe any previous results will be incorrect. I will wait with doing any further testing until I have the final version in my hands. In my previous tests, the supercaps powered the RTC (real time clock) more than seven days - much longer than expected! The results could be entirely different in the upcoming FW release and will, as I have found out, depend on many other factors like how much data is already on the card and how much data needs to be updated in the current file. I expect it could take weeks or even months to come up with realistic min. and max. values.
 
Last edited:
The lens cap just begs to get lost. I tried a lanyard but broke the tiny tab.

It would be nice if it came with a tab and really nice if it had a retainer.
◎---◯

By that I mean something like this where the lefthand one is the rimmed cap, and the right a hollow ring that snuggly fits over the lens barrel. When not covering the lens, the cap dangles from it.
 
Last edited:
Hello,

Three wishes/requests from me. Two for the camera itself (one firmware, one hardware), and one for the configuration tool.
  1. I would like to see a Linux version of the configuration tool. The config file trick is a great invention, but it still is more of a workaround than a solution. Can the Windows version, or the specs of the camera's communication protocol, be made open source?
  2. Image flip, in whatever the current recording mode is (photo, video), via a key sequence (maybe something like press and hold mode, press and release record, followed by two green led flashes for normal mode, or two red flashes for upside down mode?). Saves a few roudtrips with the config file.
  3. If in the near future there are plans for a "Mobius 2" it would be nice if it had a shape like a flashlight (might be square instead of round), with a diameter not more than the thickness of the current version. That way it could also be used inside an N-scale model train (increasing market potential of the camera).
Still, it's a great small camera...
 
The rear LED is nice BUT it would be so much nicer if it was tricolor and mimicked the top one somehow. It' s a real hassle to see the top one when hanging from the windshield mount.
 
I would like the USB socket moved from the rear to the side of the camera. This would create more space to install the camera between windscreen & rear view mirror.

H09 would achieve a similar result. Whichever is easier for the Developer to implement is fine by me.


Sent from my iPad using Tapatalk HD
 
This feature request is really more of a fantasy than anything I think would or could happen anytime soon but imagining new capabilities is worthwhile just the same. Sometimes these ideas find purchase.

I configure my Mobius using Windows 7 running on a virtual machine on my Mac. This is no problem and being somewhat of a "geek" I kind of enjoy the process. Then again, sometimes having to remove the camera from my vehicle to make some small change, like yesterday when I needed only to adjust the time stamp for daylight savings time, this can be a pain in the butt.

As a mostly Mac guy with an iPad/iPhone bias I wish someone would simply make an iOS app to match the Android app that is available for the Mobius but since that is not likely to happen anytime soon, it led me to fantasize about another way to do this......an OSD (On Screen Display) Of course, this suggestion recognizes that there is a limited amount of "space" available on the Mobius to achieve new processor and memory intensive features but this idea is nothing new and in fact I already enjoy this desired feature on a series of CCTV surveillance cameras I regularly maintain. Of course, CCTV cameras are already designed with OSD on the chip....(and so are most dash cams that do have a screen).

I always use a battery powered 7 inch LCD 720p monitor on a regular basis to configure and align CCTV surveillance cameras and I use this same monitor to align and aim the Mobius when I set it up in my vehicle.

On modern CCTV surveillance cameras there is often a small dedicated thumb operated joy stick that allows the user to control a menu driven series of settings within the camera via an external monitor. After you set up and adjust the camera, (sometimes while you are up on a ladder!) you disconnect the small monitor you've just used to access the OSD menu display (and imaging for aiming and focus). Once you now hook up the camera to the permanent cables, you are all set. So I got to imagining that this would be an excellent solution for the Mobius. Attach an external monitor to the Mobius just as you would for any other purpose and after, let's say, a 5 second press on the power button you now see a menu on your external monitor that can be operated via the three buttons on the camera (for example) - shutter button for up - mode button for down and power button for enter. Then when you are done, press the power button again for a full 5 seconds to exit. Basically, this would be a variation of the same kind of menu we see in every other dash cam that has a screen but the screen would simply be an external monitor just like is done with CCTV cameras.
 
Last edited:
Dashmellow said:
So I got to imagining that this would be an excellent solution for the Mobius. Attach an external monitor to the Mobius just as you would for any other purpose and after, let's say, a 5 second press on the power button you now see a menu on your external monitor that can be operated via the three buttons on the camera (for example) - shutter button for up - mode button for down and power button for enter. Then when you are done, press the power button again for a full 5 seconds to exit. Basically, this would be a variation of the same kind of menu we see in every other dash cam that has a screen but the screen would simply be an external monitor just like is done with CCTV cameras.
Click to expand...

plenty of action cameras out there are setup exactly like this already
 
jokiin said:
plenty of action cameras out there are setup exactly like this already
Click to expand...

Yes, I was thinking that after I posted. Perhaps this could be done fairly easily since the same components in other cams have menus. The GT3oow uses three buttons to configure the menus so as long as the Mobius buttons could be reconfigured to temporarily provide this control it might not be that difficult to achieve. Is a menu control capability already built into these chips?
 
You must log in or register to reply here.
Back
Top