GPS тракер в реално време през GSM мрежа

vladofff написа:

Може би няма да е проблем, ако става дума за едно нещо, ако са милиард и една данни обаче, след събирането им на едно място дали няма да се губи време и ресурс за парсването им от стринг в съответен друг тип.
Веднъж ми правиха забележка, че съм използвал такъв подход - имах проблеми с дата/тайм формати от/към база данни ми въртеше номера. След като ми писна, направих точно това простовато действие - данните през .ToString() и нещата се оправиха... Само, че после се забавял процеса, защото при парсването обратно в нужния тип се искало време, а това можело да се избегне. Да не би това да е проблемът?

Всичко зависи от конкретния случай.

При изключително интензивен обмен на еднотипни данни според мен е естествено да се търси минимално време за предаване на данните. В противен случай закъснението може да води до загуба на данни, поради липса на ресурс те избощо да бъдат приети и записани на сървъра.

Обратно: при слаб обмен на различни формати данни е добре те да се преобразуват като текст и след като бъдат приети от сървъра и записани в неговите бази данни, чак тогава да се анализира формата и съответно ако е необходимо различните данни да бъдат преобразувани в унифициран формат. Примерче: различни туристи, като използват различни формати, изпращат данни за текущите си координати към сървър в интернет. Тук ако координатите не се предадат именно като текст и после няма интелигентно парсване на получените данни, то координатите в по-странни формати ще бъдат отхвърлени от сървъра, няма да се запишат в базата и съответно ще бъдат безвъзратно загубени.

Това е лично мое мнение в светлината на конкретната тема. Пак да кажа, че аз се забавлявам с тези теми и мнението ми не е професионално.

lz1fw написа:

Николай_K написа:

	lz1fw написа:
	Губиш баса. Шестнайсетичното число "60636720" го предавам като текст от раз и без всякакви проблеми.

Да, ама не! "60636720" е стринг.

На никого не му пука. Имаш данни в точка А. Задачата е да стигнат без загуби в отдалечена точка Б за време В. В точка А данните тръгват като шестнайсетично число, в точка Б са получени като същото шестнайсетично число.

Останалото е даскалски манталитет за късане по изпити.
Very Happy

С риск да заприличам на досаден и заядлив даскал, трябва да кажа, че с такова изявление на изпит си за късане. Laughing

Въпросният стринг при 8-битово кодиране, представлява следната последователност от битове (MSB first):
00110110 00110000 00110110 00110011 00110110 00110111 00110010 00110000

При предаване по сериен канал за комуникация (SPI, I2C, UART, USB, GPRS, радио), работа на "приемника" е приеме и конвертира битовете в байтове. При синхронните интерфейси, това става с помоща на клока, а при асинхронните има други начини за синхронизация.
При 8-битов формат на обмен на данни, ще се предаде горната последователност от битове.

Ако същия стринг се предаде в SMS при 7-битовото GSM кодиране, ще се предадат 8 * 7 = 56 бита:
0110110 0110000 0110110 0110011 0110110 0110111 0110010 0110000

Ако обаче в SMS се използва UNICODE, ще бъдат предадени 8 * 16 = 128 бита:
00000000 00110110 00000000 00110000 00000000 00110110 00000000 00110011 00000000 00110110 00000000 00110111 00000000 00110010 00000000 00110000

И в двата случая на SMS, приемната страна ще изобрази същия стринг, защото вида на кодировката се съдържа в служебната информация на SMS.

Интерпретацията на получените байтове е съвсем друга работа и зависи от това с какъв инструмент (програмен език) се обработват данните.

В класическото ANSI C и подобните му, променлива тип "стринг" не съществува. Стрийм от байтове е най-добре да се запише в масив и след това да се обработват. Затова данните е добре да се предават не в "стрингово" кодиране, както е в примера, а по байтове с които лесно се сглобяват 16, 32 и 64 битови числа.

Питона поддържа вграден тип стринг, но и там трябва да се внимава как е кодиран стринга, защото:

	Код:
	>>> a = "60636720" >>> a '60636720' >>> int(a,10) 60636720 # грешна стойност >>> int(a,16) 1617127200 # вярна стойност >>>

В момента някъде някакви хора мръзнат по някакви склонове търсейки някого. Ако някъде на някой сървър някога имаше точните координати на този, дето го търсят, те нямаше да питат за битове, байтове, стримове, стрингове и питони. Просто щяха да си свършат работата, да се приберат на топло и може би да споменат сървъра с добра дума.

Ако обаче същите тези координати са могли да бъдат предадени по някакъв начин до сървъра, но някаква бюрократична софтуерна проверка ги изхвърлила в коша защото шестия бит в данните не е бил достатъчно шестнайсетичен и е оставила търсещите без информация ще те споменават софтуера с други думи.

Иначе всичко написано от теб е вярно, на нивото на ст.н.с. в БАН.

Аз все пак благодаря на всички, чрез дискусията ми дадохте идея, че може би трябва да тествам за потенциален проблем една система, която разработих преди 5 години. Въпреки, че работи всеки ден от толкова време, никога не е късно това да се случи и даже се сещам какво точно може да й се случи.... Ще вкарам още една проверка в приложението-изпращач, за да гарантирам, че в базата данни няма да постъпят данни, от които после приложението-обработчик да изпищи, че не му се връзват...

	lz1fw написа:
	Иначе всичко написано от теб е вярно, на нивото на ст.н.с. в БАН.

С какво те засегнах, че ме обиждаш? Wink

Тракерът е необходимо условие за спасяването на човек в беда, но не е достатъчно. Трябва още спасителите да могат навреме да достигнат мястото и да изнесат от там пострадалия. При последния случай със сноубордиста, дори да знаеха къде е той, лавинната опасност им попречи да започнат търсене.

	Николай_K написа:
	че ме обиждаш?

Леле, откога ст. н. с. стана обидно? Аз като бивш обикновен н.с. не съм вложил никакъв обиден смисъл...

Отивам да си разходя тракерите из маалата... Едни триста години трябва да топя...
Very Happy

Ами вместо да разхождаш тракера с кучетата, дай ми един на мен да го разходя по Ком-емине, ако въобще ида де. Ще взема и на цецко кучешкия нашийник, няма проблем.

	kaloyanv написа:
	Ами вместо да разхождаш тракера с кучетата, дай ми един на мен да го разходя по Ком-емине, ако въобще ида де. Ще взема и на цецко кучешкия нашийник, няма проблем.

Като наближи времето на похода ми се обади.

За колко време планираш да го преминеш? Питам, защото е много вероятно GPS/GPRS тракер на база на смартфон да не може да издържи без презареждане до края на прехода.

lz1fw написа:

	kaloyanv написа:
	Ами вместо да разхождаш тракера с кучетата, дай ми един на мен да го разходя по Ком-емине, ако въобще ида де. Ще взема и на цецко кучешкия нашийник, няма проблем.

Като наближи времето на похода ми се обади.

За колко време планираш да го преминеш? Питам, защото е много вероятно GPS/GPRS тракер на база на смартфон да не може да издържи без презареждане до края на прехода.

Ако го правя едва ли ще е за повече от 14 дни. Дори и да не мога да стигна, ще прекратя, тъй като нямам толкова свободно време. Иначе ще е септември. Не мога ли да го зареждам, аз имам много хубава батерия.

Можеш да си го зареждаш, разбира се - това е стандартен смартфон.

Покрай експериментите без SIM карта ми се върти в главата някакъв хибриден вариант, в който мобилните данни да се пускат само веднъж на ден и точките се записват през по-големи интервали от време. Това ще намали драстично консумацията, но тракерът ще престане да бъде в реално време.

Не ми стана ясно - това само тракер ли е или търсиш и beacon функция?

Ед.: Няма как да е в реално време, освен ако не се примиряваш с изпуснатите отчети в моментите без връзка. Това как го отиграваш?

_________________
Бутам след осмата бира Very Happy

	dido написа:
	Не ми стана ясно - това само тракер ли е или търсиш и beacon функция? Ед.: Няма как да е в реално време, освен ако не се примиряваш с изпуснатите отчети в моментите без връзка. Това как го отиграваш?

Под тракер разбирам проследяващо устройство. Под beacon - устройство, периодично излъчващо определени сигнали. GPSlogger, предаващ GPS координати на сървър в интернет, според мен има и двете функции.

GPSlogger може да се програмира през какъв интервал от време да предава координатите и другите данни. Аз предпочитам това да става през 30 секунди и за моите разбирания това е в реално време. Може би защото самият аз се движа бавно. Very Happy

Без да съм го изпробвал, при предаване през малки интервали от време вероятно ще има проблеми с предаване на данните към сървъра, особено ако данните са много. А по време на пробите аз нарочно карам GPSlogger да предава абсолютно пълния възможен набор от данни.

Освен че предава данни към сървър в интернет, GPSlogger ги съхранява и в собствената памет на смартфона. При това го прави в доста различни формати. Аз ги запазвам едновременно и в .CSV и в .GPX формат.

Ако т.н. тракер (да не повтарям непрекъснато GPSlogger, инсталиран на смартфон с Андроид) попадне в зона на пълна липса на GSM покритие данните не се губят, а се запомнят от устройството и се предават в момента, в който GSM обхвата се появи. Дотук е доказано, че помни поне 272 точки.

Ако тракера е в място с лошо, ама не абсолютно никакво покритие, това е проблем. Данните заминават към сървъра, устройството ги отчита за предадени и не ги запомня, а сървъра не успява да приеме нищо. Тези моменти при лошо покритие още ги изследвам, но нещата изглеждат да са така. Точки се губят не при никакво, а при някакво, но лошо покритие.

Ясно. Тракер, не работи в реално време, с ограничена beacon функция.

Добра beacon функция не може да се отиграе от смартфон. основно щото комуникационния канал минава през GSM свързаност или през WiFi (само в комбинация с търсещо устройство). Тези два канала понякога имат ниско availability в планински или аварийни условия.

Ако към тези два канала добавиш сателитната джаджа, показана от Ведрин заедно с някаква нискочестотна система за радио засичане, спомената от Николай, ще получиш един приличен beacon. Той обаче може да бъде единствено embedded устройство.

Връщам се на тракер-функцията в телефон, каквато си тръгнал да правиш. Ето няколко идеи:

- отчетите влизат във FIFO, заградено от два адаптивни филтъра. Първият на входа филтрира темпото на отчетите по скорост на придвижване. По-висока скорост - по-чести отчети и обратно. Вторият филтър на изхода филтрира самото съдържание на отчета по качество на връзката. При влошаване на връзката - стъпаловидно дропиш все повече данни почвайки от най-ненужните - примерно махаш първо DOP-ове, сетне сателитното инфо и прочее;

- можеш да реализираш приоритетно FIFO, в което наред с отчетите "стандартен приоритет" да имаш и такива с "висок приоритет" (напр. SOS функция), които да бъдат източени първи при наличие на връзка.

_________________
Бутам след осмата бира Very Happy

Последната промяна е направена от dido на Чет Апр 01, 2021 8:42 pm; мнението е било променяно общо 1 път

Ще помисля.

Но още съм далече от сериозен проект.
Very Happy

lz1fw написа:

Ако тракера е в място с лошо, ама не абсолютно никакво покритие, това е проблем. Данните заминават към сървъра, устройството ги отчита за предадени и не ги запомня, а сървъра не успява да приеме нищо. Тези моменти при лошо покритие още ги изследвам, но нещата изглеждат да са така. Точки се губят не при никакво, а при някакво, но лошо покритие.

Пропуснах това - малко ми е мътно как се получава описания ефект.

Ако ползваш http POST, при успех на заявката сървърът съвсем стандартно би трябвало да ти отговори с 200, 201 или 202. Друг отговор или липсата на отговор в някакво приемливо време - примерно 20 сек, можеш да приемеш за счупено предаване и да пробваш пак.

_________________
Бутам след осмата бира Very Happy