Jediné co zatím nemám odladěné je kmitočet. Potřeboval bych na to THD-710, která jako první má tlačítko které by mělo umožnit automatické naladění na základě takovéhoto objektu...

Super, to je presne to, aby se u toho nejprve premyslelo, nez se to nejak zacne pouzivat... i kdyz samozrejme pro prehlednost na mape by bylo "hezci", kdyby se zobrazoval nazev prevadece, ale kmitocet je take prakticka informace...

Cili ted idelane takovy objekt pokusne vysilat a najit nekoho, kdo s THD-710, ale take s VX-8R apod...

No a snad misto toho R70k bych dal R70km a pak by bylo vhodne zapracovat info o tom, zda ma prevadec CTCSS jen ny vystupu nebo je pod nim i plne ci castecne zavreny, tedy neco jakoT088_in/out
T088_-/out
T088_in+3db/out
1750&T088_in/outapod... nechci to komplikovat, ale uvaha dopredu se vyplati, nez se to zacne prosazovat do praxe...

Aha, tak to jsem asi vzal moc zjednodušeně ale každopádně s Tebou souhlasím že je dobře to probrat, prodiskutovat a vyzkoušet, než pak kvůli pitomosti předělávat hromady blbě definovanejch objektů... To co jsem psal jsem si nevytáhl z paty, ale postupoval jsem podle doporučení Boba http://aprs.org/localinfo.html a http://aprs.org/info/freqspec.txt (doporučuji přečíst celé) kde se mimo jiné píše:
;FFF.FFxyz*111111zDDMM.hhN/DDDMM.hhWrTnnn RXXm NETxxxxxx MTGxxxxx .........

Where ;FFF.FFxyz is the frequency, and "xyz" are optional local unique characters
or ;FFF.FF5yz for 5 KHz repeaters and "yz" is one of over 3600 unique characters A-z, 0-9
or Example "xyz"s might be -IA for Iowa, -A for Atlanta, *SD for SanDiego, etc
Where *111111z is the pseudo default null Date-Time field for the OBJECT format
Where DDMM.hhN/DDDMM.hhWr is the LAT/LONG and "r" symbol for a voice repeater
Where Tnnn is the tone in Hz (without tenths) and RXXm is the range in Miles
Where Netxxxxxx is the local weekly net time (if any)
Where MTGyyyyy is the monthly club meeting time (if any)
Where ... are 9 more bytes of optional text that will not be displayed on most mobiles but are visible on other clients
First line (10 bytes Tnnn RXXm ): (has a trailing space as a delimiter)

T079 R45m -(Combines 79.7 Hz PL tone and Range (miles or Kilo) on the first line.
t079 R45m -(the lower case letter means narrowband modulation.
D234 R45m -(Combines DCS code and Range on the first line.
1725 R45k -(1725 Hz tone and range in kilometers
Toff R45k -(Tone is OFF (no PL or CTCSS))
E45m W15m -(No tone. Shows different ranges N/S or E/W (here, 45m east and 15m west)
Second Line (10 bytes NETxxxxxx ): (has a trailing space as a delimiter)

Net Tu9PM -(if it has regular nets worthy of note to visitors
Net M 9PM -(For one letter days)
Net Tu730 -(another example assuming all nets are PM)
144.875rx -(optional if repeater has a non stndard RX split)
Third Line: (8 bytes MTGxxxxx):

Mtg3rd W -(for meetings on M, W or F
Mtg3rdTH -(for meetings on Tu, Th and Sa or Su
Additional text:... Following the above 28 bytes, additional text may be included for APRS clients and home stations, but it will not show up on the D7 or D700.

Na první pohled mi to celkem dávalo logiku, nejsem si jist, jestli když místo "k" pro kilomety nebo "m" pro míle (km a mi jak píšeš) nerozhodíme nějaké SW nebo rádia, která tyto stringy budou podle této specifikace rozklíčovávat. Zatím jsem ještě neukecal kluky s TM-D710 abychom vyzkoušeli kompatibilitu.

no, ma to autor prokombinovany jako hlavicku nejakyho souboru, ale mysli lokalne a jedna globalne... jestli toto ma byt nejakym standardem pro vyrobce nejakych radii a firmware se podle toho ma nejak ridit, tak potes panbuh... to abychom to prohlasili za americkou normu a sami si udelali evropskou...

myslim to obecne, ale cisi z toho ten omezeny amerikanismus

on to (pokud to dobre chapu) prizpusobuje 10mistnym displejum - SW pozna, kde konci hlavicka (znakem "r") a odtam to zacina vypisovat na displej:T079 R45m - CTCSS 79,7 Hz, dosah 45 mil
Net M 9PM - převaděčový kroužek (též zvaný dědkorunda) vždy v pondělí ve 21:00
Mtg3rd W - pravidelná měsíční klubová setkání každou 3. středu v měsíci
..........- následuje volných 28 bytestakže to jakoby napíše pěkně pod sebe... to je celé kouzlo protokolu... čili když hodíme do kyblu věci, které se na starém kontinentu už prostě nenosí, jako na převaděčích (drtivé většině) pravidelné kroužky, nebo IMHO pro APRS (projíždějícího či náhodného) uživatele v daném místě naprosto nepodstatná informace o slezinách (nějakého) klubu (když ani neříkám KDE se koná), tak nám zbývá prostoru habaděj. Přinejmenším je tam prostor pro ten znak km. První řádek chápu ještě jakž-takž jako nositele exaktní informace, i když nejpodstatnější je info o kmitočtu, příp. nestadardním odskoku a způsobu "nahození".

Tedy by to taky mohlo vypadat takto (pokud tam ponecháme trochu té angličtiny):Tx -700kHz- informace o nestadardním odskoku
T088 R40km- CTCSS 88,5 Hz, dosah 40 km (využívá se i 10. znak na řádku)
NETd9PMz - kroužky denně ve 21:00z
..........- následuje volných 28 bytes na cokoliv

např:

RXinfoPLS
kokoska@se
znam.czčili jinými slovy bych to nebral jako dogma, ale jako možnost kombinovat určité skupiny informací a to tak, aby byly čitelné na 10znakových displejích... (i když toto taky neberu jako dogma, jen jsem to odtušil jako nějaký záměr autora... nevím, zda mají ty handheldy 10zn displeje, ale odpovídalo by to...) Sám SYSOP vidí, co potřebuje sdělit jako nejnutnější věc - tzedy ne to, že tam bývá nepravidelná dědkorunda, ale to, že to má z jakýchsi důvodů nestandardní odskok a že by rád poslechové reporty...

no, ma to autor prokombinovany jako hlavicku nejakyho souboru, ale mysli lokalne a jedna globalne... jestli toto ma byt nejakym standardem pro vyrobce nejakych radii a firmware se podle toho ma nejak ridit, tak potes panbuh... to abychom to prohlasili za americkou normu a sami si udelali evropskou...

myslim to obecne, ale cisi z toho ten omezeny amerikanismus

on to (pokud to dobre chapu) prizpusobuje 10mistnym displejum - SW pozna, kde konci hlavicka (znakem "r") a odtam to zacina vypisovat na displej:T079 R45m - CTCSS 79,7 Hz, dosah 45 mil
Net M 9PM - převaděčový kroužek (též zvaný dědkorunda) vždy v pondělí ve 21:00
Mtg3rd W - pravidelná měsíční klubová setkání každou 3. středu v měsíci
..........- následuje volných 28 bytestakže to jakoby napíše pěkně pod sebe... to je celé kouzlo protokolu... čili když hodíme do kyblu věci, které se na starém kontinentu už prostě nenosí, jako na převaděčích (drtivé většině) pravidelné kroužky, nebo IMHO pro APRS (projíždějícího či náhodného) uživatele v daném místě naprosto nepodstatná informace o slezinách (nějakého) klubu (když ani neříkám KDE se koná), tak nám zbývá prostoru habaděj. Přinejmenším je tam prostor pro ten znak km. První řádek chápu ještě jakž-takž jako nositele exaktní informace, i když nejpodstatnější je info o kmitočtu, příp. nestadardním odskoku a způsobu "nahození".

Tedy by to taky mohlo vypadat takto (pokud tam ponecháme trochu té angličtiny):Tx -700kHz- informace o nestadardním odskoku
T088 R40km- CTCSS 88,5 Hz, dosah 40 km (využívá se i 10. znak na řádku)
NETd9PMz - kroužky denně ve 21:00z
..........- následuje volných 28 bytes na cokoliv

např:

RXinfoPLS
kokoska@se
znam.czčili jinými slovy bych to nebral jako dogma, ale jako možnost kombinovat určité skupiny informací a to tak, aby byly čitelné na 10znakových displejích... (i když toto taky neberu jako dogma, jen jsem to odtušil jako nějaký záměr autora... nevím, zda mají ty handheldy 10zn displeje, ale odpovídalo by to...) Sám SYSOP vidí, co potřebuje sdělit jako nejnutnější věc - tzedy ne to, že tam bývá nepravidelná dědkorunda, ale to, že to má z jakýchsi důvodů nestandardní odskok a že by rád poslechové reporty...

No, je otázkou jestli je to amrikanismus a nebo je jestli to je tím že Bob WB4APR APRS vymyslel a výrobci SW a HW zakomponovávají jeho doporučení. (Yaesy, Kenwood, UI-View, APRS-SA....) Vemu jako příměr WX stanice. taky jde o textový řetězec, ale zkus změnit pořadí nebo do něj zasáhnout a uvidíš, co se začne dít za věci. Některé SW to pochopí, některé z toho budou mít rozsypaný čaj, jiné už to zobrazí jako pouze řetězec znaků. Zatím jsem to podrobně nezkoumal, jestli to u vysílání objektů nemůže být podobné. Pakliže by šlo jen o to, že je to rozděleno po 10ti znacích jen kvůli tomu, že některá rádia mají 10zn. na řádek bylo by to to nejmenší zlo. (tím mám na mysli třeba že místo "k" použijeme "km") takovýto SW nebo HW pak můžeme celkem kvalitně zblbnout. Stejně tak s odskoky a dalšími položkami specifikovanými ve výše uvedeném dokumentu. Proto jsem chtěl vyzkoušet jak se bude chovat TMD-710, protože tam vím, že už se umí "naladit" a předpokládám že soudruzi v Japonsku budou vyžadovat jednoznačný string aby tato operace dopadla dobře.
Jinak co se týče těch kroužků myslím, že ty dodatečné informace se nevysílají pořád, ale jen určitý čas pře jejich konáním a tyto objekty jsou "dynamické" k tomu třeba slouží SW http://wd5eae.org/APRSEditor.html kde si lze zadat scheduler podle kterého se daný objekt s připraveným textem vysílá. Každopádně se nijak nebráním Tvému návrhu, nejde o život a přinejhorším si přiděláme trochu práce v případě, že se objeví a začne používat SW nebo HW, který "naši" syntaxi neschroupne.

Tady je videt, jak zobrazeni na TM-D700 simuluje rozhrani APRS4R:

Proste vezme to, co je za urcitou sekvenci znaku (kterou muze pouzit ve svuj prospech napr. pro naladeni na kmitocet) a vezme to jen jako jakousi textovou zpravu a vypise to do 4 radku po 10 znacich...

A jestli se nekde nekdo neco zacina prosazovat jako norma jen proto, ze se na jednu stranu vyrobci boji, aby jim neujel vlak a na druhou stranu se uzivatele nezajimaji o tom, jak by to mohlo vypadat, aby to vypadalo lepe... tak je prave nejvyssi cas zacit nahlas hovorit o tom, ze pokud norma, tak zajimava a pouzitelna pro vsechny... tedy i za ucasti evropskych uzivatelu...

Tady je videt, jak zobrazeni na TM-D700 simuluje rozhrani APRS4R:

Proste vezme to, co je za urcitou sekvenci znaku (kterou muze pouzit ve svuj prospech napr. pro naladeni na kmitocet) a vezme to jen jako jakousi textovou zpravu a vypise to do 4 radku po 10 znacich...

A jestli se nekde nekdo neco zacina prosazovat jako norma jen proto, ze se na jednu stranu vyrobci boji, aby jim neujel vlak a na druhou stranu se uzivatele nezajimaji o tom, jak by to mohlo vypadat, aby to vypadalo lepe... tak je prave nejvyssi cas zacit nahlas hovorit o tom, ze pokud norma, tak zajimava a pouzitelna pro vsechny... tedy i za ucasti evropskych uzivatelu...

Jo, samozřejmě jak to vypadá na D700 vím, můžu to vyzkoušet i na D7 a VX8, ale pokud je mi známo (zatím jsem neměl možnost to vyzkoušet) aktivně by se s tím měla vypořádat D710 (tj. měla by se na základě takovéhoto objektu naladit) a jelikož je to v současné době jediné mobilní rádio které je v prodeji rád bych, aby převaděče byly zadány tak, aby to fungovalo (samozřejmě při splnění podmínky že to bude rozumě čitelné i pro ostatní uživatele). Pořád trochu nerozumím tomu, proč dělíš Evropské a Americké uživatele, čím se to liší? Převaděče mají všude frekvenci, subtón a odskok... a je jedno jestli je to v čechách nebo na floridě... Akorát že někde je -1,6 MHz, někde 5MHz, někde 7,6 MHz...