|
|
Line 9: |
Line 9: |
|
4 - 1 gab. |
|
4 - 1 gab. |
|
* Ja neizmantotu palīglīdzekļus, varētu būt vairāk astotnieku. |
|
* Ja neizmantotu palīglīdzekļus, varētu būt vairāk astotnieku. |
|
|
|
|
|
|
|
|
== Projekta (C) daļas komentāri == |
|
== Projekta (C) daļas komentāri == |
|
|
* Vislabāk C daļā studentiem veicās arhitektūras un problēmu sadaļā un komponentu darbības aprakstos - aprakstīt problēmas un vispārīgu arhitektūru mācēja labi. Vissliktāk - sistēmas priekšrocību un trūkumu aprakstā (daļēji tāpēc, ka tas bija pēdējais jautājums, vairāki cilvēki nebija paspējuši uzrakstīt, kā varēju noprast). Cilvēki nemāk novērtēt savu risinājum. Visgrūtāk izdodas tieši atrast pozitīvo. |
|
⚫ |
* Visiem vēlams rakstīt precīzi par to kas prasīts. Nevis , piemēram, arhitektūrā par sensoriem, par kuriem pēcāk tiek aizmirsts. |
|
* Zemāk doti projektu komentāri, gan pozitīvie gan kritika. |
|
* Zemāk doti projektu komentāri, gan pozitīvie gan kritika. |
|
Studentu vārdi nav doti un saraksts nav sakārtots, bet ceru ka paši sapratīsiet kurš ir jūsu projekts pēc būtības, un lasīt komentārus par citu versijām arī ir vērtīgi. |
|
Studentu vārdi nav doti un saraksts nav sakārtots, bet ceru ka paši sapratīsiet kurš ir jūsu projekts pēc būtības, un lasīt komentārus par citu versijām arī ir vērtīgi. |
|
|
|
⚫ |
* Visiem vēlams rakstīt precīzi par to kas prasīts. Nevis arhitektūrā par sensoriem, par kuriem pēcāk tiek aizmirsts. |
|
|
|
|
|
|
{| border=1 cellspacing=0 cellpadding=4 |
|
{| border=1 cellspacing=0 cellpadding=4 |
Line 100: |
Line 103: |
|
* Nav novērtējuma – plusi un mīnusi |
|
* Nav novērtējuma – plusi un mīnusi |
|
|} |
|
|} |
|
|
|
|
|
|
|
|
= KD2 = |
|
= KD2 = |
Revision as of 23:49, 16 November 2009
KD1
Vispārīgie rezultāti un secinājumi
9 - 2 gab.
8 - 0 gab.
7 - 2 gab.
6 - 7 gab.
5 - 0 gab
4 - 1 gab.
- Ja neizmantotu palīglīdzekļus, varētu būt vairāk astotnieku.
Projekta (C) daļas komentāri
- Vislabāk C daļā studentiem veicās arhitektūras un problēmu sadaļā un komponentu darbības aprakstos - aprakstīt problēmas un vispārīgu arhitektūru mācēja labi. Vissliktāk - sistēmas priekšrocību un trūkumu aprakstā (daļēji tāpēc, ka tas bija pēdējais jautājums, vairāki cilvēki nebija paspējuši uzrakstīt, kā varēju noprast). Cilvēki nemāk novērtēt savu risinājum. Visgrūtāk izdodas tieši atrast pozitīvo.
- Visiem vēlams rakstīt precīzi par to kas prasīts. Nevis, piemēram, arhitektūrā par sensoriem, par kuriem pēcāk tiek aizmirsts.
- Zemāk doti projektu komentāri, gan pozitīvie gan kritika.
Studentu vārdi nav doti un saraksts nav sakārtots, bet ceru ka paši sapratīsiet kurš ir jūsu projekts pēc būtības, un lasīt komentārus par citu versijām arī ir vērtīgi.
Risinājums
|
Pozitīvais, labās idejas
|
Kritika
|
X
|
- Ļoti labs problēmu un risinājumu uzskaitījums
- Labs sensoru/resursu uzskaitījums
- Apzinās, ka enerģiju var netaupīt, nevajag duty cycle
- Ir paketes formāts, bez izmēriem
|
- Nav konkrēta komunikācijas protokola
- Ko nozīmē "laiku pieturā sinhronizē manuāli"? Kurš tad ies un uzstādīs pulksteņus?
- Apgalvo, ka "strādā ātri un uzticami" - bez pamatojuma
- Ceļa kvalitātes dati pakās nekur neparādās
|
X
|
- Komunikācijas protokols labi aprakstīts – kurš kuram kad pārsūta, kurš pieglabā
- Iztiek bez sensoriem :)
|
- Reģistrē tikai autobusu pienākšanu pieturās, pa ceļam neko nemēra
- Aprakstīta arhitektūra, bet nav ne uzskaitītas problēmas, ne doti risinājumi
- Jauc jēdzienus "sensors" un "sensoru mezgls/mote"
- Sensorus vispār neizmanto, bet neko nepamato
- Nesaka tieši, kādu CSMA protokolu lietu un cik lielas paketes
- Nav minētas sistēmas priekšrocības
|
X
|
- Piedāvā risinājumu, ja pieturām nav elektrības. Apzinās, ka enerģija ir problēma
- Piedāvā pieturu motēm gulēt, kad autobusi nekursē (naktī)
- Labs stils – viss pa punktiem
- Labs komunikācijas protokola apraksts – ar skaitliskām vērtībām
- Perfekts komponenšu lomu apraksts
|
- Nav skaidrs, kāpēc sastrēgumu identificēšanai vajadzīgs accel un bedru noteikšanai "kustības sensors"
|
X
|
- Labs arhitektūras apraksts
- Labs zīmējums
- Ideja – pieturās kustības sensors, kas detektē autobusu piebraukšanu
- Vibrācijas sensors seguma kvalitātes mērīšanai
|
- Kustību sensors pieturās diez vai strādās efektīvi
- Nav skaidrs, kā identificē sastrēgumus
- Nav skaidrs, kādus datus katrs saglabā – ierašanos pieturās?
- Lieto "kādu no reaktīviem" routing protokoliem. Kam vajadzīga routēšana 1-hop tīklā?
- Lieto MAC DCF. Kā to saprast?
|
X
|
- Vispārīgi aprakstījis, ka dati no pieturām tiek pārsūtīti uz WiFi ar autobusu forward
|
- Piedāvā sastrēgumu identificēt pēc autobusa atpalikšanas no grafika, ko fiksē pietura. Tas nav korekti.
- Sašvīkājis veselu lapu, tad piedāvā citu variantu – ar GSM. Nošvīkātais būtu labāks variants.
- Komunikācijas protokols, datu struktūras, priekšrocības, trūkumi un ceļa seguma mērīšana nav vispār minēta
|
X
|
- Labs arhitektūras apraksts
- Labs sensoru (accel) pamatojums
- Izmanto accel gan sastrēgumu, gan bedru noteikšanai
- Precīzi kritēriji, kā identificēt sastrēgumu un bedri. Precīzs cilvēks
- Labi aprakstītas paketes (izņemot izmērus) un komunikācijas protokols
- Min komunikācijas protokola optimalitāti – flooding strāda visefektīvāk, ja nav kolīziju
|
- Nav skaidrs, kāpēc vajag duty cycling
- Nav pakešu izmēru
|
X
|
- Skaists zīmējums, lai arī neko daudz neizsaka :)
- Precīzi aprakstīts, kā rēķina pavadīto laiku, kā būvē pakas, ko pieglabā
- Min, ka uz serveri sūta vispirms jaunākos datus, tad vecākus – cik nu paspēj
- Nododot datus autobusam, kam ir WiFi, iztīra buferi, jo zina, ka tie nonāks serverī
- Sensorus neizmanto vispār
|
- Komunikācijas protokolam daudz sarakstīts, bet daļa nesaprotama, daļa lieka
- Min, ka autobusam vajag 2 radio, lai var vienlaikus runāt ar pieturu un busiem. Bet nav aprēķina, kas pamatotu, ka datu būs tik daudz, lai nepaspētu visu nosūtīt
- Nav novērtējuma – plusi un mīnusi
|
KD2
Nav vēl noticis