Fysikk og teknologigreier
Vi veit at mange av dykk likar å mekke rundt. Så, for dei interesserte og motiverte studentane, her er meir informasjon og DIY-programvaregreier.
BLE Reklameinformasjon
Merk: Om de har forslag til korleis forklaringa kan bli betre, så bruk detaljane.
For dei tøffe sjelane med pågangsmot til å lage sitt eige datainnhøstingsutstyr, så gir vi informasjon om BLE-reklameprotokollen som BroodMinder bruker. Faktisk bruker vår eiga BroodMinder-CELL, WiFi og -SubHub reklamen til å avlytte enhetane og deretter videresende data direkte til MyBroodMinder.com.
Det finst fleire gode BLE Explorer-program tilgjengelege. Våre favorittar er:
- Android & iOS – nrfConnect av Nordic Semiconductor. Android-versjonen er den beste, men vi bruker begge to heile tida. Den har ein fin signalnivågrafikkfunksjon.
- PC – Bluetooth LE Explorer av Microsoft. Dessverre viser ikkje dette programmet reklamedataene.
- Mac – BlueSee – Denne appen ser ut til å fungere bra og den viser produsentdataene i reklamepakka.
Du vil truleg legge merke til at dei første 3 bytane av enhets-ID-en alltid er 06:09:16, deretter følgjer den spesielle enhets-ID-en som alltid er Modell:ID:ID. Nokre enheter (iOS & Mac) gøymer den sanne ID-en, så vi inkluderer også den i namnfeltet i den utvida reklamepakka.
Sammensetning av Reklamepakka for BroodMinder
Når du les reklamepakkane frå BLE, kan du identifisere BroodMinder-produkt ved å sjå på følgjande.
Dataen vil sjå noko slik ut – dette eksempelet er frå einheit 43:30:07
GAP Skanningssvarhending ------------------------------------------------------------------------------------
ble_evt_gap_scan_response: RSSI=-77, pakketype=0, avsendar=[ 07 30 43 80 07 00 ], adressetype=0, bond=255, data=[ 02 01 06 02 0A 03 18 FF 8D 02 2B 15 02 00 02 21 00 D0 62 00 FF 7F 05 80 37 07 30 43 00 00 00 ]
Merk: Verdiar er i desimal såfern ikkje framført med 0x
1) Sjekk for "Spesifikk data frå produsent" flagg Bytar 6,7 = 0x18, 0xff
2) Sjekk for IF, LLC som produsent Bytar 8,9 = 0x8d, 0x02
Bytar 10-29 er dataen frå BroodMinder som skissert under. EnhetsmodellIFllc_1 = 0x2b (43d = vekt) EnhetsversjonMindre_1 = 0x15 (21d) EnhetsversjonStørre_1 = 0x02 (FW 2.21) Forløpt_2V2 = 0x21 (33d) Temperatur_2V2 = 0x62d0 VektL_2V2 = 0x7FFF VektR_2V2 = 0x8005
Kartlegginga for alle modellane er på neste side
PRIMÆR | ||||
---|---|---|---|---|
Byte | Type | Verdi | Parameter | |
0 | Annonseringsfeltlengde | 02 | ||
1 | Feltype | 01 | Tilkoblingsbar | |
2 | Verdi | 06 | LE Generell Oppdaging, Tilkoblingsbar, Enkeltmodusenhet | |
3 | Annonseringsfeltlengde | 02 | ||
4 | Feldtype | 0A | Sendestyrke | |
5 | Verdi | 03 | Styrke i DB | |
6 | Annonseringsfeltlengde | 24 | ||
7 | Feldtype | FF | Produsentdata | |
8 | Verdi | 8d | IF, LLC = 0x028d, 653 | |
9 | Verdi | 02 | IF, LLC = 0x028d, 653 | |
10 | Verdi | Modell | ||
11 | Verdi | Versjon Mindre | ||
12 | Verdi | Versjon Større | ||
13 | Verdi | Realtidstemperatur 1 | 47/49/56/57/58 (SM og XLR) | |
14 | Verdi | Batteri | ||
15 | Verdi | Tid gått | ||
16 | Verdi | Tid gått | ||
17 | Verdi | Temperatur | 47 og over er centicenigrader + 5000 | |
18 | Verdi | Temperatur | ||
19 | Verdi | Sanntid Temp2 | 47/49/56/57/58 (SM og XLR) | |
20 | Verdi | VektL | ||
21 | Verdi | VektL | ||
22 | Verdi | VektR | ||
23 | Verdi | VektR | ||
24 | Verdi | Luftfuktighet | vil være 0 for 41/47/49/52 | |
25 | Verdi | VektL2/SM_Tid0 | 49/57/58 (XLR) | |
26 | Verdi | VektL2/SM_Tid1 | 49/57/58 (XLR) | |
27 | Verdi | VektR2/SM_Tid2 | 49/57/58 (XLR) | |
28 | Verdi | VektR2/SM_Tid3 | 49/57/58 (XLR) | |
29 | Verdi | Sanntid totalvekt / Svermtilstand | 47/49/56/57/58 (SM og XLR) | |
30 | Verdi | Sanntid totalvekt | 47/49/56/57/58 (SM og XLR) | |
SEKUNDÆR | Utvidet Annonsenettverk | |||
Byte | Type | Verdi | Parameter | |
0 | Annonselengde | 09 | ||
1 | Type | 09 | Fullstendig lokalt navn | |
2 | 4' | ASCII-navn | ||
3 | 2' | |||
4 | :' | |||
5 | 0' | |||
6 | 0' | |||
7 | :' | |||
8 | 0' | |||
9 | 0' |
Merk: BRM52 BroodMinder-SubHub er forskjellig som forklart nedenfor.
Her er ligningene
hvis (Modellnummer == 41 | Modellnummer == 42 | Modellnummer == 43)
{
temperaturgraderF = e.data[byteNumAdvTemperatur_2V2] + (e.data[byteNumAdvTemperatur_2V2 + 1] << 8);
temperaturgraderF = (temperaturgraderF / Math.Pow(2, 16) * 165 - 40) * 9 / 5 + 32;
}
ellers
{
dobbelt temperaturgraderC = e.data[byteNumAdvTemperatur_2V2] + (e.data[byteNumAdvTemperatur_2V2 + 1] << 8);
temperaturgraderC = (temperaturgraderC - 5000) / 100;
temperaturgraderF = temperaturgraderC * 9 / 5 + 32;
}
luftfuktighetProsent = e.data[byteNumAdvFuktighet_1V2];
hvis (Modellnummer == 43)
{
vektL = e.data[byteNumAdvVektL_2V2 + 1] * 256 + e.data[byteNumAdvVektL_2V2 + 0] - 32767;
vektSkalertL = vektL / 100;
vektR = e.data[byteNumAdvVektR_2V2 + 1] * 256 + e.data[byteNumAdvVektR_2V2 + 0] - 32767;
vektSkalertR = vektR / 100;
}
ellers hvis (Modellnummer == 49 | Modellnummer == 57 | Modellnummer == 58)
{
vektR = e.data[byteNumAdvVektL_2V2 + 1] * 256 ```
-
e.data[byteNumAdvWeightL_2V2 + 0] - 32767; weightScaledR = weightR / 100; weightL = e.data[byteNumAdvWeightR_2V2 + 1] * 256 + e.data[byteNumAdvWeightR_2V2 + 0] - 32767; weightScaledL = weightL / 100; weightR2 = e.data[byteNumAdvWeightL2_2V2 + 1] * 256 + e.data[byteNumAdvWeightL2_2V2 + 0] - 32767; weightScaledR2 = weightR2 / 100; weightL2 = e.data[byteNumAdvWeightR2_2V2 + 1] * 256 + e.data[byteNumAdvWeightR2_2V2 + 0] - 32767; weightScaledL2 = weightL2 / 100; } realTimeTemperature = ((float)(e.data[byteNumAdvRealTimeTemperature2] * 256 + e.data[byteNumAdvRealTimeTemperature1] - 5000) / 100) * 9 / 5 + 32;
realTimeWeight = (float)(e.data[byteNumAdvRealTimeWeight2] * 256 + e.data[byteNumAdvRealTimeWeight1] - 32767 ) / 100 ; SM_Time er tida i unix-format for siste temperaturhending. Time0 = LSB, Time3 = MSB, det vil være tida sidan oppstart dersom tida ikkje har blitt sett inn i enheten ved ein enhetssynkronisering.
BRM-52 BroodMinder-SubHub
-SubHub gjer nokre snedige annonseringar. Annonsen endrar seg kvar 5. sekund for å sende ut ein annan enhet. Den vil rotere gjennom alle enhetar (inkludert seg sjølv) og deretter gjenta.
Vi kallar desse falske annonseringar. Avhengig av kva operativsystem som blir brukt, kan du eller du ikkje (f.eks. iOS) sjå den sanne enhets-ID-en (f.eks. 06:09:16:52:01:23). Det er derfor vi plasserer enhets-ID-en i den utvida annonseringsbyten. Ver også merksam på at det kan vere vanskeleg å lese den utvida annonseringa for nokre enheter, men for dei kan du typisk lese den sanne enhets-ID-en.
Den falske ID-en ligg i byte 13, 19, og 30. Dette gjer prosessen slik:
- Fastsett om dette er ein -SubHub ut frå ID-en (enten den sanne ID-en eller ID-en i den utvida annonseringa). Det vil alltid være 52:xx:xx.
- Dersom det er ein "52"-enhet, pars bytes 13/19/30. F.eks. 43/01/23 vil vere 43:01:23
- Pars resten av annonsepakka i samsvar med enhetstypen basert på modellbyte (byte 10)
Lett som eit egg 😉
Fysikk for BroodMinder-W
Det er mange måtar BroodMinder kubevekta kan brukast på, og sidan den berre måler ein brøkdel av den totale kubevekta, blir designet og plasseringa av den tilleggse støtten og BroodMinder skalaen ein integrert del av det totale kubevektsmålesystemet. Generelt sett, jo meir innsats ein legg i dette, jo betre resultat vil ein oppnå. Kubesupportsystema vist nedanfrå går frå det enklaste til det mest sofistikerte med størst usikkerheit til lausning. Det er opp til den individuelle brukaren å avgjere kva ein skal implementere.
MERK: den mest typiske feilkjelda er utilstrekkeleg støtte under skalaen. Dette kan resultere i underleg oppførsel når kuben bøyer seg medan den utvider seg og krympar seg på grunn av sol, regn, temperatur, osb. Å gi ei flat støtte vil betre resultatane. Eit enkelt triks er å plassere eit ¾” kryssfinerark (eller tilsvarande) under skalaane.
TILLEGGSNOTAT: Dersom du berre vil sjå honningflyta, treng du ikkje god støtte. Du må berre ignorere dei daglege svingningane. Du vil framleis kunne observere den totale veksendringa.
a) Standardoppstilling
Dette er standardoppstillinga med skalaen framme på kuben og ein 2×4 som ei tilleggse støtte (vippepunkt) bak:
Her er nokre berekningar knytt til setupen:
Forutsetningar
Kubevekta W er jamt fordelt og massens tyngdepunkt er midt i kuben. For enkelheit, blir ikkje framspringet på bunnen av brettet framme vurdert. Kubevekta blir ført som 100%.
Berekningar
Når du bruker vanleg 2×4 trelast som bakstøtte og justerer den med baksida av kuben, kan den totale kubevekta W reknast ut frå vekta på skalaen S som:
Derfor, bruk 2.09 som standard kubevektfaktor i appen dersom du brukar denne oppsettet. Dette kan sjølvsagt finjusterast når vektmålingar er tilgjengelege.
Diagrammet nedanfor viser skala korreksjonsfaktor for ulike skala- og vippepunktoppsett. X-Aksen er posisjonen til vippepunktet i tommer frå baksida av kuben. Dei ulike linjene representerer skalesenterlinjeposisjonen i tommer frå baksida av kuben. Pilane viser eksempelet over.
b) Alternativ oppstilling 1
Basert på det over, bør den tilleggse støtten plasserast 1” frå baksida av kuben. Det blir tilrådd å feste ein trimdel på toppen av 2×4-en. Dette vil hjelpe for nøyaktig posisjonering av den tilleggse støtten.
No ``` me har like lange arms E og F, og kuben skala korreksjonsfaktor blir 2,0 som er standard i den mobile appen. Det er imidlertid noen andre påvirkningsfaktorer som ikke bør overses. Det virkelige vippepunktet for den hjelpende støtten er hvor som helst mellom baksiden av kuben og fronten av den hjelpende støtten på grunn av variasjoner i nivået på støttesystemet og potensiell vridning av 2x4-enheten.
c) Alternativ ordning 2
Et annet støttesystem kan brukes som har et definert vippepunkt og ikke påvirkes av justeringen av støttestrukturen:
Ta en bit furu eller eik, ca. ¾” tykk og 2” bred. Lengden må være bredden på kuben. Skjær et lite snitt i den. Snittet må være like dypt som sagbladets bredde. Fest denne delen til undersiden av bunnskiven til kuben. Juster den flush med baksiden. Plasser deretter en bit 1” med 1/8” 6061 eller 6063 aluminiumsvinkel, samme lengde som trestrimmelen, under den for å støtte kuben. Hjørnet på aluminiumsvinkelen hviler i snittet. Den totale høyden på aluminiumsvinkelen og treverket må være lik eller litt større enn skalahøyden for å sikre at kuben er nivå eller til og med litt vippet fremover for å sikre at vann dreneres bort fra kubeinngangen.
d) Lateral balansERING
Alle de overnevnte støttesystemene påvirkes av udefinert lateral vektoverføring siden kuben hviler på mer enn tre punkter. Det er to punkter foran inne i kubevekten og en lineær støtte på baksiden av kuben. Dette kunne føre til overbelastning på en av lastcellene i skalaen, og derfor kreves det som regel lateral balansering hvis støttesystemet under kuben ikke er en kontinuerlig plattform, dvs. separate betongklosser for fronten og baksiden av kuben.
Les vekten fra hver lastcelle individuelt ved å bytte til sanntidsvisningen med appen. I denne modusen vises vekten på skalaen som %Venstre, %Høyre. Høyresiden av skalaen er siden med enhetens identifikasjonsmerke. Ingen ytterligere handling er nødvendig hvis L/R forskjellen er mindre enn 10%.
Hvis ikke, støtt skalaen på siden med lavere vektavlesning til vektavlesningene stemmer overens. Alternativt kan støtting også gjøres under bakstøtten på motsatt side av den lave vektavlesningen.
e) 3-Punkts Kube Støtte
Det er en måte å avhjelpe behovet for lateral balansering ved å introdusere et ekte 3-punkts støttesystem. Delene ligner på de som brukes i ordning 2, men i stedet for å bruke en 1” vinkel, trenger du her en ¾” vinkel. Det bores et 7/32” hull i midten av brettet i stedet for å skjære et snitt. En ¼” x 0,5” sporingsmaskinskru bruker som sentralt støttepunkt. Skruen vil skjære sine egne gjenger i brettet. Sporet i skruens hode er justert slik at den kan hvile på kanten av aluminiumsvinkelen på ett punkt uten å gli av.
Det er en liten klaring mellom aluminiumsvinkelen og trebrettet. Det må sikres at denne klaringen er jevn bredde over hele kuben. Skruen i midten skal være det eneste kontaktpunktet. Dette vil sikre at riktig vekt måles og samtidig fungere som "sikkerhetsnett" mot at kuben velter hvis overdreven ujevn belasting finner sted, f.eks. under kubeinspeksjoner.
f) BroodMinder Skala Plassering
Det meste av det ovennevnte har å gjøre med den hjelpende støtten. La oss nå fokusere på skala plasseringen.
Som vist i de tidligere avsnittene, er det ønskelig å ha fremsiden av skalaen plassert i linje med fremsiden av kubelegemet. Å flytte den lenger inn ville forbedre nøyaktigheten på bekostning av kubestabiliteten, og å flytte den lenger ut ville redusere nøyaktigheten med lite forbedret kubestabilitet.
Denne tabellen viser påvirkningen av skala plassering på skala korreksjonsfaktoren og skalafeilen introdusert på grunn av unøyaktig plassering av skalaen. Innflytelsen er 5,6% per tomme
Det er tilrådelig å merke skala posisjonen på bunnskiven til kuben eller å feste et mekanisk stopp. Dette vil hjelpe med å sette skalaen tilbake på samme sted etter at den er trukket ut for et batteribytte eller en annen grunn.