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

Илкоре, а отвори чекмеджето и виж дали наистина са налични тези 7 бройки дето се мъдрят на сайта ви.

Не, но живо ме интересува какво е положението, ако пробваш, кажи.

Мисля да свържа два-три към USB-тата на компа и да ги разцъкам с командите на ръка, а после да ги интегрирам в новия дивайс. Търся ниска консумация и детектване на липсата на връзка със своя смартфон за да се задейства GSM (за сега).

Вече са две бройките ...

Аз поръчах на нашето МТО да ми доставят 5, та може липсващите 5 да са за мен. Мерси!

От скоро се замъчих с това RN4020. Гадина е...
Основни недостатъци - за сега:
1. крака който казва има ли конекция или няма е малко луд. Мърда, бави се, а дори някой път не мърда...
Обяснение на ситуацията.
Ако зададеш команда свързване (на централата) - модула влиза в режим на свързване и така стои во век и веков.
Тоя режим може да бъде прекратен само по 3 начина (според мене):
- ти та си го спреш с команда от централата.
- да се свържеш, при което получаваш отогвор "Connected" и да се вдигне крак че си се свързал. Е тука са първата част от проблемите. Крака, че си се свързал, се вдига малко след започване на изпращането на стринга "Connected". Някъде по време на първото 'n'. Тоест закъснява. Предполагам онова вътре тъпче стринга в буфер за изпращане и после отива да вдигне крака, а през това време изпращането си въври. При прекъсване на конекцията крака се бави по същия начин - само че двойно повече. Явно между изпращането на стринга и кода за местене на крака има повече "код". Реално модула почва да връща "Connection End", а крака пада накъде около 't'. Както и да е, винаги има ситуация, при която ако гледаш само крака, интерпретираш една част от връщания стринга като валидни данни, малко преди или малко след движението на крака. Един вид крака не е синхронизиран вътрешно така ,че след като мръдне, всички следващи байтове да са валидни данни и обратното.
- третия и последен начин да се излезне от режим на свързване на централата е, след зададена команда за свързване, централата да върне директно "Connection End", все едно вече сме били свързани за момент, ама после веднага след това връзката се е разпаднала. Важно е да се отбележи че ПРЕДИ ТОВА НЕ Е ВЪРНАЛА "Connected", а връща направо "Connection End". Предполагам, че такова положение се случва, когато модулите са на ръба на обхвата, и просто за момент става свързване, ама веднага след това се разкачат, с което реално прекратяват и по-нататъшните опити да се свързват, защото реално прекратяват и режима за свързване. Режима за свързване може да бъде активиран само с изпращане на нова команда за свързване.
Е тука почват майтапите.
При описаното горе положение, крака за конекция също изобщо не мърда, ама по големия проблем е, че ако някой път модулите се закачат и останат закачени, крака за конекция на централата се вдига коректно, ама крака за конекция на периферията си остава с ниско ниво. Все едно нямаме конекция. А конекция има и трансфера си върви. В интерест на истината трябнва да отбележем, че връщаните стрингове поне от страна на централата са коректни. Само трябва да се абстрахираме от това, че при зададена команда за свързване и моментално последвало разкачане, централата първо не връща "Connected" и след това "Connection End", както е логично и според мен по-правилно, а връща направо "Connection End", нищо че преди това реално не е докладвала, че вече е имало връзка, па макар и за кратко.

Та, извода е, че краката вече не са това което бяха. Не може да им се вярва много много.

Инак обхват има, обаче трябва да се спазва правилото от пдф-а да се осигури пространство около антената. Не търпи писти или мад около нея и вярно не търпи. Пробвахме го.
Как ще е при реален трансфер на данни, още незнам. Не сме стигнали до там. Предполагам ще ползваме MLDP режим на 7кб без подтвърждение. За нашата работа става...

Тая работа отива на тотален провал.
Сега и друг пин го хванахме да прави бели.
Flow Control не работи нещо като хората.
Уж нормално работи, ама по някое време - като вземе модула да се разкача и CTS-са остава вдигнат за постоянно. И няма сваляне.
После ти какво да му пишеш, като той неще да взима нищо. А инак си се връзва, развързва и принципно сякаш работи, щото другите пинове си работят, ама тоя от UART-a си седи залепил горе и това е.
Шантава работа.
Може и у нас някъде да е причината, ама много конспиративна трябва да е!

Разбира се, че задклавиатурното е осрало работата!
Само че е двустранно - не е само при нас де...

Оказа се, че баш в режима дето тестваме, съм забравил да вдигна двата пина WAKE_HW и WAKE_SW.
Инак в другите режими (смяна на софтуер и разни служебни съм ги вдигал, ама баш в нормалния режим съм го изтървал.
То вярно, че и то не си е вдигнало пина че е активно, ама пък и аз не го гледам, щото какво да му гледам като "знам", че със сигурност съм го запалил. Пък нали и ако не съм, трябва да е умряло и да не можем да си приказваме. Е уж трябва да е умряло, ама не е. Буди се само и пак отговаря.

Какъв е обаче е резултата, след като оправихме пиновете?

По всички закони това не трябва да работи със свалени тия пинове - да, ама работи.
Явно влиза в нещо като SLEEP режим, (то така и трябва) ама при получаване на байт се буди и работи. И това със СВАЛЕНИ ПИНОВЕ. Баси и чудото.
Единственото само при паленето омазваше първия байт - този който реално го буди. После ако продължаваш да пращаш постоянно, комуникацията върви. Ако правиш обаче малки паузи, пак заспива и после при това недокументирано будене, пак изтърва първия байт.
Ние пък, голямо чудене се чудехме, що такя яко омазва първия байт от пакета, а после вървят. Както и да е де...
Единственото което се подобри след като оправихме пиновете е, че вече не омазва първия байт.
Крака, че има конекция на периферията пак не се вдига някой път. В такъв случай не се праща и информационния стринг.
Разминаването между крака и информационен стринг отново си е същото.
Flow Control-а продължава да залепя някой път, при разкачане подари лоша връзка. При осъществяване на нова най-често не се разлепя сам.

Решението, или по-скоро решенията поне за сега се изразяват в следното:
Оказа се, че FLOW KONTROLA няма смисъл да се гледа, ами си правим протокол да познава кой байт за какво е и да прихваща началото на пакета, и така предаващото предава постоянно, без да се съобразяваме с FLOW контрола. Въведохме и правило, че при осъществяване на всяка нова конекция, централата трябва да очаква да получи веднага определени данни от периферията. Ако не получи, явно имаме ситуация, при която периферията не е разбрала, че имаме конекция. В такъв случай, централата минава сама в CMD режим, разкача връзката и опитва отново да я закача. И така докато периферията се "абариса" и почне да предава.
Относно проблема с FLOW контрола. Там се оказа, че при осъществяване на нова връзка, ако продължим да пишем от периферията към централата, най-често трансфера продължава без да се налага да правим каквото и да е, и това въпреки че и пина си продължава да стои залепен горе.
В случай, че трансфера тръгне по тоя насилствен начин, тогава и пина на FLOW контрола сам се "разлепя" и почва да работи нормално.
Някой път, много рядко обаче, трансфера не тръгва по тоя начин, но тогава пък, при следващо разкачане по инициатива на централата и ново закачане, трансфера гарантирано продължава. Ако неще, пак разкачане и закачане, фокато тръгне. За сега повече от 2 поредни пъти не се е налагала тая гимнастика. Та в крайна сметка и това не се оказа непреодолим проблем...

Сега и нещо положително да кажа за това RN4020:
Като се закачи един път, после държи връзката стъбилно, стига да не е на границата на обхвата де.
То и някак, когато си на границата, неще да се закача. Явно при закачане иска малко по-добър сигнал от колкото е нужен за да крепи после връзката, и щом има достатъчен сигнал за да се закачи, значи и след това ще успява да държи стабилна връзка.
Потока с данни (ползваме MLDP2), някой път позабавя за малко според състоянието на връзката, но после се оправя и като цяло е добре. Също така много рядко бърка байт, нищо че трансфера в този режим не е гарантиран.

Та... борбата продължава...!
Някой друг не го ли бори и той това, че да каже и той впечатления?
Поздрави на всички!

разгледай сорса на Android Explorer 16 RN4020 PICtail Demo Code
http://ww1.microchip.com/downloads/en/D ... 20Code.zip

Явно влиза в нещо като SLEEP режим... влиза - избрал си такъв модул дето ти пази батерията и си обърни внимание на пиновете за контрол на WAKE

То страшното мина.
Подкарал съм го вече, и си работи до степен да върши това за което го гласим.
Ама както казах, другите проблеми си остават, а аз нямам контрол над тях. Само разни софтуерни "замазки" отгоре.

Относно кода на Microchip, разбира се, че съм го гледал. Обаче то пък кой може да ги разбере тия техните драсканици.
Добре, че процесорите ги правят по-скопосно отколкото някои от примерите си, че инак майка плаче...

Относно модула, никак нямаме опит с BT, та тоя го избирахме щото евтин, лесен за употреба (поне така изглеждаше на пръв поглед), а и не на последно място лесен за доставяне и монтиране. Повечето по-маркови са само с падове отдолу. А върви ги подкарвай такива. То платки, стенсили и т.н. и то само за да го видиш какво може. Че и по 40-50 лв броя...
В началото докато това микрочипското нещеше да тръгне, доста се оглеждахме и за други, даже купихме едни панасоници да са при нас за по-бързо, ама значително повече пари, иска външен клок и т.н...

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

nRF518xx, bluegiga

Да попитам нещо извън темата за RN4020: може ли по BT да се изпращат SMS-и ? Постановката е микроконтролер през BT да се свързва към GSM телефон и да изпраща от време на време SMS-и. Ако може, кой BT profile е за тази цел ? Има ли някакви особености от страната на телефона, т.е. по документация какво трябва да има като хардуер/софтуер телефона ?

По принцип може да стане. Ама май ще ти трябва стара бизнес нокия.
Трябва ти БТ модул за 3.20$ http://www.ebay.com/itm/30ft-Wireless-B ... 3cf66498ed
Свързва се към телефона с Serial Port Profile (SPP) и с АТ команди пишеш СМС и пращаш.