DIY Datafield replacement is now Hundsmiachns DIY Datafield

Hi

For status updates you will have to read my latest posts in this thread, when it is usable for the masses I will make a new thread.

This is the new thread for a replacement of the great DIY datafield from  which is not developed anymore.

So I decided to code my own datafield based on his idea of importing the whole layout as a configuration string.

Discussion started here:

https://forums.garmin.com/developer/connect-iq/f/app-ideas/165670/replacement-for-diy---do-it-yourself-datafield---fully-customizable-data-field/958769#958769

XML was my first idea, because it is easy readable. But for now I am implementing the parsing of the settings string as a ";" list. So every value, type, setting is in this list as the config string. How to get this string easily from a readable format I will think of later. Today I added basic elements like text, line, circle and rectangle. Which values to display is my next task, speed, cadence, power, heartrate etc....

I will post the source code when I have finished the basic implementation. I am rather new to monkey c, so I still have to learn, but it seems not really that complicated.

Config string will look like this, short description below. It will look little bit different for every elementtype.

V;113311;120;100;HRT;0;C;%.2f;1;5@$G;LIN;5566FF;60;60;140;180;8@$G;CRF;AABB00;50;50;20

V: Value field
113311: RGB Color value
120: X coord
100: Y coord
HRT: value type heartrate, many more to come
0: font type 0-17   (FONT_XTINY, ...)
C: Center alignment
%.2f: floating precision
1: Outline true/false
5: Number of samples
@$: Separator for each element
G: graphic element
LIN: line
5566FF: color
60: X Coord
60: Y Coord
140: X Coord end
180: Y Coord end
8: line width
@$: Separator for each element
G: graphic element
CRF: circle filled
AABB00: color
50: X
50: Y
20: Radius

Here a screenshot of some random elements displayed, to test the parsing of the string.

A description what values are needed for each elementtype will follow later.

regards

Erich

  • Really nice that you try to code a replacement for the DIY datafield!
    I will really appreciate a replacement - currently I use a user defined DIY page at my Edge 1030 which has some bottlenecks / bugs...

    My 2cents about the configuration (I've no knowledge about Connect IQ programming, so I've no idea what's possible and what's not...):
    No matter which format or mechanism you use to transfer a configuration from PC to the device - make sure it can be set and transferred with BaseCamp.
    The original DIY uses string(s) which needs to be transferred - and the BaseCamp was only able to transfer only 256 Bytes (AFAIK); so if you had complex layouts which need two or three strings - you'd were not able to set and transfer it with BaseCamp - you had transfer the strings from the PC to your phone and there you could put it in the ConnectIQ-App (via copy and paste) which then transferred it to the datafield at the device.
    Very complicated --> so try to make it better in your replacement Wink!

    Another thing: make sure the encoding for the configuiration text is UTF (e.g. UTF-8) so that the user is able to use special characters (e.g. German umlauts)...

    And about the layout itself: I'm not sure about what's possible and what not - but for my Edge 1030 you must not use the complete screen - you can put a datafield to a region of the screen (depends on what layout you choose) - so the datafield should be somehow able to detect it's maximum possible size...

    It would also be nice and useful to not only have centered alignment but also left and right alignment...

    And what does the line number in the above example mean?
    If you define an element shouldn't it either be positioned absolutely (with given some start position in pixels and a dimension or angle or... - dependent on the type of element) or relatively to another element or aligned to another element or the screen/maximum space itself (left, centered, right)?!
    And what if elements overlap?
    How do you define which one is "more in the foreground" as another?
    Isn't some kind of layering / stacking necessary for this?

  • Hi

    I quite dont understand the problem with basecamp. Basecamp can only transfer one setting with a maximum length of 256 bytes ? Can there be more than one settings field? If so, I would make multiple setting fields each with a maximum of 256 bytes, would this solve your problem?

    Maybe you could give an example, if a layout has a string with length 800 bytes, how should I import it into the datafield?

    UTF8 import will work from the start, I am from Austria, so I need "Umlaute" myself.

    In the datafield you check in which quadrant you datafield is, but I think it doesnt matter, because you give absolute x/y coords in the string so you can configure it yourself.

    Alignment is possible left/right and center of course.

    Coords are absolute and the background of every element is transparent, so its no problem if they overlap.

    What do you mean with line numbers ? The config string in the above example is only in the first line, all other lines are only the description of the config string in line 1.

    And yes, I have added layering as well, z coord is increased with every element I import, so the first element in the string is the one farthest in the background, the last in the string is in front. But I could add a z coord as parameter in the string, so you can set it yourself.

    Maybe you could post a screenshot of your datafield, later on I will try to replicate it in my datafield.

    regards

    Erich

  • I don't understand the problem either - but the author of the original DIY field had such problems.
    If you use the DIY Data Field Designer and your design is too big and you press "import/export" there is a warning message saying "THIS CONFIGURATION CAN ONLY BE SENT TO WATCH VIA GARMIN CONNECT MOBILE!" (and not with Garmin Express - "Basecamp" was wrong...)
    Here is the current design which I use at my Edge 1030: 

    AOaBRASHCOBIAAOE]CPISOIAWAALJNCDAAAAABEABAkkuASHFM\PAAJOHXVBDAQAYHFOXSC_QADCVRBAOADAADBAVAFJ^WA[AAAAABEAB%s%AQHKPHECEAAAAAAIAVAOAU`CDAAAAABCABGPSAQHR_TBAHJOHXVAIAQHR_TBAHQAF_PAHAUH`V\AAFEXUL\IUABDRBHAALKFCDAAAAABEABGeschwindigkeit (km/h)AWHKPM[ACJOHXVEIAXGWDBA\HKPM[E\WS`CQEIAVGWTBAAFQ\ATABKL_CDAAAAABCAB0AUAOXKFCDAAAAABCAB60AZAALKZAKAAAAACEABavg %fFAZAPULAALAAAAACAABmax %fFAUALYQBCDAAAAADEABkmATALYQXCDAAAAADEABhAVAHVCWAJAAAAAHCAB%fGBGAALNWCDAAAAABEABTrittfrequenz (1/min)ASHDYOUAAJOHXVGUAOAYHD[KXCTWVWPPWSAMACAAD[ATAAPGNCDAAAAABEAB0AVAPUORCDAAAAABAAB125AYAALPFAQAAAAACEABavg %sAYAPUPNARAAAAACAABmax %sASAIBKaAPAAAAAGCABAUH`WACAFEXUL\IUABC[AUHKPNRABEXUL\EJABMMA[AALQGCDAAAAABEABHöhe (m)AZAHRO\ATAAAAABAAB/\ %s mAWAALSGBTAAAAABEAQ%fE%AZAHRQ\AUAAAAABAAB\/ %s mASADa]\ASAAAAAGCABA_AIMVYCDAAAAABEABStrecke (km)A^APUSOBUAAAAABAABnoch %fF kmAVAMBBMAMAAAAAGCAB%fKAZAALTACDAAAAABEABUhrzeitAaAALVBAZAAAAABEACZielankunft %sASADa`SABAAAAAGCABAXAIMYSCDAAAAABEABDauerAZAPUVJAFAAAAABAACnoch %sAVAMBEDADAAAAAGCAB%fGAUH`WFVABAAAAAITABMMBFAALV[CDAAAAABEABHerzfrequenz (1/min)A[APUWBAaAAAAABAABZone %fEAYAALWXAWAAAAACEABavg %sAYAPUW`AXAAAAACAABmax %sASAIBSTAVWY]^_GCABEEMJNATXDWHODA^SDHCODU]`B\UABG`[AYIAB[`GAAAJOHXVADVJNATXADLODA^SADGODU]`AC[ABG`[ACOAB[`GABRODU]`AAAEXUL\AFFJNATXAE`ODA^SAEXODU]`AD`ABG`[ABWAAAAAAAAEXUL\

    If you first select "Edge 1030" as device and then import the above string and try to export it again you'll see that warning message...
    I don't know what the exact problem (or even the exact limit) is - but there is one Worried

    And here is a screenshot of the design (from the above designer, not from the device itself - at the device it looks slightly different):
    /resized-image/__size/282x469/__key/communityserver-discussions-components-files/11/DIY_5F00_Bodenseematze.jpg


    Forget what I said about line numbers - I misinterpreted the "LIN: line" in your example as line number Blush

    To replicate my datafield you'll need graphic elements - so I assume it'll take a while until it's possible to do that Laughing

    Altogether it seems you already did a lot of thinking and planning - that's really promising! Thumbsup tone3

    regards,
    Bodenseematze
    P.S.: don't we need a fresh new name for your datafield so that we don't need to always talk abot "the original DIY datafield"?

  • Hi

    I have now the basic elements finished. Available value types for now are heartrate, % maxhr, avg pace, current pace, distance, timer time. I will add many more later on, for now I am concentrating on stability and memory usage.

    Graphics elements which work are line, rectangle and circle.

    One big issue is memory usage. Because the memory in these apps is quite limited I only can fit about 30 elements into one datafield on my 935. I will try to improve that later on. Dont know how much a Edge 1030 can handle.

    Dynamic colors also work. I have added 5 different colors for 5 different heart rate zones and 5 colors for 5 different paces.

    Here is a screenshot of a first version of my datafield:

    I had to change the config string because of these memory issues. It is basically the same as above but has now fixed length values, so no ";" needed and the numbers are in hex format. Config string for the above datafield looks like this:

    Desription will follow later.

    GRF0000FF000700990100E20055@$GCR00AAFF0078007802007602@$GLN00AAFF000900500300E8005002@$GLN00AAFF000600990400EB009902@$GLN00AAFF0070009906007000BD02@$GLN00AAFF001700BD0500D800BD02@$VFX55555500A3000C0700100%@$VFX55555500BC00A10800200km@$VHPFFFFFB0078000F0980101@$VHRFFFFFA001900350A00201@$VCPFFFFFC007800560B80105@$VAPAAAAAA0044009C0C50101@$VDSAAAAAA00B6009C0D52001@$VTTAAAAAA007800C20F50101@$CFFFFFA007448000800690FF000005DCFFFF00055A00FF000000FFFFFF@$CFFFFFB003BA800080035EFF00000301FFFF0002BF00FF000000FFFFFF@$CFFFFFC1002D8000800032FF00000037FF5500003C00FF0000410055FF5546FFFFFF

    Here is the original old datafield I created with  datafield designer for comparison.

    In the weekend I will try a run with new datafield to check the "real world" (-:

    PS: I called the field "MiachField", but I am open to suggestions ;-)

    regards

    Erich

  • looks promising, good luck on the project.

    it would probably be best to create a  new thread in the showcase forum as this is no longer an app idea but a project in progress.

  • Hi

    Thanks .... As I am still learning monkey C which is rather different to Java in how to write the code (no pretty const variables, etc ). I also gave up that the code is easy readable and editable by others, because of the below restrictions, code does not look as pretty as it should.

    I will make a new thread when it is usable for the masses. For now I have to write the config string by hand. For me its easy because I made it, but for others its much harder I think. So a GUI is needed which creates the string and I have no clue yet where and how to make this GUI. I already uploaded a beta version to garmin. Is it possible to share this link to some testers or as I understand it, is it only visible to my account?

    @Peter: Maybe you have some more coding advices to save some memory. What I learned so far regarding memory usage:

    (just a conclusion of this thread: https://forums.garmin.com/developer/connect-iq/f/discussion/6000/preserving-memory-in-monkey-c in which you already posted)

    * const variables are bad.

    * avoid switch case statements, use if

    * avoid repeated code, use functions instead

    * don't use dictionaries

    * set all variables to null by default.

    * use float instead of double if precision is not needed.

    * remove System.println, every line of code takes up memory.

    A thing I have not implemented is using a 32bit Number for storing 2 small variables (coordinates for example). I will add the bitshifting next.

    One more thing: I tried my code with the edge 1030 and there, memory is not as much of a problem I think. I was able to add about 250 elements before I got a out of memory.

    regards

    Erich

  • I am following this with great interest since i love DIY Datafield. Looking forward to some easier configuration, though :-)

  • A little status update.

    Basic implementation of the datafield is finished, optimized as much as I could. FR935 can handle now about 30 elements.

    I started making the GUI Designer. It will be a Win32 application. Because I dont have any experience in javascript, and I already made some MFC applications, the decision was to use VisualStudio with MFC.

    I know, a javascript site would be better because its platform independent, but I would need to learn javascript before, and I dont have the time for it at the moment.

    To be clear, there will be no application for Linux or MAC, don't bother asking. I dont use them and I have no time to implement the GUI a second or third time on different platforms.

    If someone finds a easy way to convert a .exe file to Linux or MAC, be my guest ....

    regards

    Erich

  • A big part of the DIY Designer GUI is finished. The only problem I have left is displaying the texts with accurate fonts. Because the garmin fonts are not publically available, I have to search for similar fonts which match the garmin ones.

    So, the fonts and the alignment of the texts is not ok, but the rest works fine. Text will have a gradient if a dynamic color is assigned to it.

  • Keep up the good work.

    Looking forward to trying it.

    Have you thought about several apps so people can use more than one custom screen?