[EL] Draadloos netwerk voor TI rekenmachines

[Verwijderd]

Ik keek eens rond op ticalc.org, en daar zag ik dat iemand een stukje electronica had gebouwd waardoor je het linkkabeltje tussen twee Texas Instruments rekenmachines kon vervangen door 2 kastjes die draadloos communiceerden, en een linkkabel 'simuleerden'.
Toen kreeg ik dus het idee een heel netwerk van die dingen te bouwen, aangezien ik zelf in assembler voor de rekenmachine kan programmeren.
Het kastje dat op die site stond leek me niet erg praktisch (De status van elk van de twee draadjes in je linkpoort wordt gewoon letterlijk overgezonden, ook geen error checking, collision avoiding e.d.), dus besloot ik dat er een nieuw ding ontworpen moest worden.
Ik surfte een beetje rond en kwam op het volgende uit (na hier de search te hebben gebruikt): Radiometrix BiM2-433
Het probleem is dat dit ding een bidirectionele poort nodig heeft van een byte groot, en de rekenmachine maar een (bidirectionele, half-duplex) seriele poort van 2 bits groot heeft.
Mijn vraag is dus aan jullie: Hoe bouw ik iets dat de communicatie regelt tussen de rekenmachine en de radiomodule?
Het mooiste zou zijn als de 'converter' een PICje is met wat RAM zodat hij zelf regelt wanneer hij iets zendt en ontvangt. De rekenmachine kan dan op willekeurige momenten iets in het buffer schrijven (verzenden-wachtrij), of eruit lezen.
Ook is het wel handig als dat PICje de aanmelding bij het netwerk regelt etc, en pakketjes weggooit als ze niet voor hem bedoeld zijn.

Ik vraag geen kant-en-klaar schema, maar zou graag weten hoe ik in godsnaam aan zoiets begin, wat ik zoal nodig heb en hoeveel het gaat kosten

[MewBie]

ik zie een heleboel mogelijk heden met zo'n syteem chatten tijdens een proefwerk ofzo

[Verwijderd]

MewBie schreef op 03 September 2003 @ 14:19:
ik zie een heleboel mogelijk heden met zo'n syteem chatten tijdens een proefwerk ofzo

Als t je lukt kun je er grof geld mee verdienen vlak voor de examens

[Ibex]

als je wilt met aanmelden en het weggooien van pakketjes, dan heb je denk ik ook al een overdrachtsprotocol nodig, zodat de machines elkaar weten te onderscheiden, en om een protocol te ontwerpen moet je toch al heeel goed zijn denk ik...

iig; good luck.

[Verwijderd]

Ik kan je er weinig overvetellen, maar ik hoop iig wel dat het je lukt, zoals In_The_Aire al zei kan je er naar mijn idee ook een hoop geld mee verdienen

[Verwijderd]

Je zal er waarschijnlijk niet onderuit komen een microcontroller te gebruiken voor je protocol. Je TI is beperkt in geheugen en om daar een compleet protocol in te fabriceren is waarschijnlijk teveel van het goede.
Kortom, het is niet echt bepaald makkelijk om zoiets ff te maken.

[Oguz286]

Damn dat wil ik ook bouwen trouwens er is zo'n gast die al een netwerk van Ti rekenmachines heeft gebouwd, alleen is dat met kabel... Ik zal ff kijken

Damn, kan hem niet vinden, maar ik weet zeker dat ik hem heb gezien. Die man had 4 Ti's aangesloten op een netwerk, maar hoe dat weet ik niet meer

[ Voor 35% gewijzigd door Oguz286 op 03-09-2003 15:47 ]

[Dr Nix]

Leuk plan
Als je meer dan 2 ti's wil aansluiten (draadloos of met draad) zie ik 2 mogelijkheden: 1) er is een serverkastje, waar alle verbindingen heen gaan, en het verkeer onderling regelt of 2) idere ti is aangesloten op dezelfde bus, dat is makkelijker te maken draadloos, maar je moet aan collision-detection/avoiding gaan doen.
Ik wil eventueel wel meehelpen als je al een beetje opweg bent.

[Verwijderd]

wij hebben dit destijds met een infrarood poort gedaan op het Gym, en dat werkte min of meer.
*Ergens* heb ik er nog tekeningen en beschrijvingen van, als jullie die kunnen gebruiken hoor ik het wel...

[Stalkert]

* Stalkert ziet het al helemaal voor zich. Mijn vriendin met laptop / boeken / etc in de kantine en ik een proefwerk maken.

Zou inderdaad mooi zijn als het werkt.

[Verwijderd]

Het protocol heb ik al ongeveer uitgedacht:
- Je eigen rekenmachine luistert een paar seconden (5 ofzo?) wie er allemaal 'on the air' zijn
- Hij kiest een random getal tussen 1 en 254 (255 = broadcast), die hij niet 'gehoord' heeft tijdens de vorige stap
- Vervolgens gaat hij om de 3 seconden een pakketje naar adres '0' sturen met daarin zijn eigen adres
- Zodra hij zijn eigen adres hoort, begint hij weer van voren af aan met aanmelden (als bijvoorbeeld twee netwerken samengevoegd worden doordat ze naar elkaar toe bewegen en ze elkaar opeens kunnen horen)

Ik denk wel dat dit te doen moet zijn met een PIC i.c.m. die module, maar ik heb dus geen idee hoe ik alles op elkaar aan moet sluiten. Er zal in ieder geval iets in moeten komen wat hele nibbles tegelijk kan lezen en in z'n buffer zetten, en die er vervolgens weer uit kan lezen als seriële data. Op zich is het niet erg als hij zijn hele buffer in 1x leeggiet naar de rekenmachine toe, het splitten van de pakketjes kan namelijk ook daar gebeuren, aangezien je op de gemiddelde PIC toch wat minder mogelijkheden hebt dan op de Z80-processor in de rekenmachine.

/me hoopt op een electronicamaster hiero

[ Voor 13% gewijzigd door Verwijderd op 03-09-2003 16:25 ]

[Verwijderd]

dit bestaat al voor de TI-93 ofzo. die heeft zo'n infra rood ding standaard ingebouwd. misschien kan je een schema vinden waarop staat hoe die werkt. die infra rood reciever zit dan alleen wel erin gebouwd en is dus niet verbonden met de link kabel. maar misschien kun je bij de TI-83 er ook wel iets op solderen. ik weet alleen niet hoever het bereik is. meende iets van 20 m

ik kom via www.ticalc.org ook op deze site:

http://sami.ticalc.org/irlink/e_intro.htm

misschien staat hier iets interesants (zelf nog niet gekeken)

vertel wel effe hoe je het gedaan hebt als het werkt. dit willen veel mensen hebben zo voor het examen (zoals ik

[Verwijderd]

Ehm, de bedoeling is dus dat het gewoon door de ether gaat, dus _niet_ via infrarood. Daarmee kun je namelijk maar 2 calcs met elkaar verbinden, en je kunt er niet mee door muren, boeken, pennen of handen.

@Dr. Nix:
Die radiomodule heeft ingebouwde collision avoiding

[ Voor 15% gewijzigd door Verwijderd op 03-09-2003 16:48 ]

[Verwijderd]

zou dat ook werken op een casio
Hier gebruiken we de CFX9850 serie, geen TI

[Rein_stein]

hehe...volgens mij komt er dan een complete antene op je bureau te staan . Als je t allemaal erg klein kan maken, dan heb je lol..:D

*bookmarked

[Verwijderd]

Niet te vroeg bookmarken, ik weet niet eens of het überhaupt echt haalbaar is, onder andere qua kosten
In de datasheet van de radiomodule staat dat je een aantal verschillende soorten antennes kunt maken, en al die antennes passen in de rekenmachine (je kunt gewoon een spoortje op de PCB als antenne gebruiken). Dat zou dus geen probleem moeten zijn.
Het ding is trouwens 3,3 x 2,3 x 0,4 cm, dus ik denk dat als het PCB'tje een beetje compact blijft het allemaal gaat lukken, desnoods achterop de LCD (dat ding zit vast met een bijna massieve plaat RVS van 2,5mm dik ofzo, dus die breekt echt niet).

Uit de datasheet:

[ Voor 6% gewijzigd door Verwijderd op 07-11-2003 10:46 . Reden: plaatje mirrored ivm bandwidth ]

[Rein_stein]

de kosten zullen niet zo hoog zijn. wat kost een PIC nou? dat zijn de kosten niet. die troep eromheen ook niet echt. Ik denk dat een nieuwe TI t duurste gaat zijn, mocht je m slopen..

verder is t idd wachten op iemand die goed PICs kan programmeren.
Ik zal eens een topic openen op CircuitsOnline, kijken ofzij kunnen helpen...

[Kawaii]

een PIC is idd niet zo duur, en je moet natuurlijk ook iemand hebben die een beetje goed met PIC's overweg kan

Ik heb toevallig vandaag net een nieuwe TI gekocht (TI-83 Plus Silver Edition). dus gelijk maar ff gebookmarked

[Verwijderd]

Rein_stein schreef op 04 September 2003 @ 19:24:
de kosten zullen niet zo hoog zijn. wat kost een PIC nou? dat zijn de kosten niet. die troep eromheen ook niet echt. Ik denk dat een nieuwe TI t duurste gaat zijn, mocht je m slopen..

verder is t idd wachten op iemand die goed PICs kan programmeren.
Ik zal eens een topic openen op CircuitsOnline, kijken ofzij kunnen helpen...

Heb ik al gedaan, aangezien hier niet echt bruikbare replies kwamen

Het grootste probleem is niet de PIC programmeren; dat kan ik ook wel (leren). Er moet alleen wel iemand langskomen die weet hoe alles op elkaar aangesloten moet worden

[den 150]

Deze is misschien ietske beter beschikbaar (weet niet waar de eerst vermelde chip verkrijgbaar is...)
http://www.velleman.be/common/product.Aspx?id=351532 (Velleman code XTR-434L , als de site weer tegenwerkt). Daar vind ik wel niet direct zoveel info van terug als de datasheet van de 1e, maar ik blijf zoeken...

[edit] http://www.radio-tech.co....n_XTR-434_User_Manual.pdf (na 2 seconden google )

[ Voor 15% gewijzigd door den 150 op 05-09-2003 10:10 ]

[Rein_stein]

kut, heel nieuw topic gestart

[Verwijderd]

@den 150:
Zo te zien heeft dat velleman ding geen collision avoiding of error checking, en dat is nou juist waarom ik die radiometrix module wilde gebruiken

[cold45]

k weet niet hoe groot verschil dr zit tussen Texas Instruments en Casio's kwa data versturen, maar k hoop dat die 2 wat dat betreft compatible zijn, dan heb ik wat extra hulplijnen tijdens reps/tentames/examens

[Verwijderd]

cold45 schreef op 04 september 2003 @ 19:58:
k weet niet hoe groot verschil dr zit tussen Texas Instruments en Casio's kwa data versturen, maar k hoop dat die 2 wat dat betreft compatible zijn, dan heb ik wat extra hulplijnen tijdens reps/tentames/examens

Dan zul je toch zelf je software moeten schrijven aangezien het standaardprotocol van Texas Instruments / Casio maar 2 calcs ondersteunt (en bijzonder brak is, maar dat terzijde). Maar zolang het linkpoortje 3 draadjes (2x data + ground) heeft die vanuit een programma afzonderlijk te schakelen & uit te lezen zijn moet het wel lukken

[Vold]

Umm, Is het eigenlijk mogelijk dat die ingebouwde antenne (of chip), storingen kan veroorzaken in je rekenmachine ? Of zeg ik nu iets heel doms

Verder is dit een heel interessant idee Ga ik zeker in de gaten houden !

[Verwijderd]

Ik denk niet dat het signaal daar sterk genoeg voor is. Andersom zou wel kunnen, als ie af is moeten we dan nog ff testen welke antenne de beste ontvangst geeft... maar het duurt nog wel ff voor die af is

-edit-
Is er nou echt niemand met kennis van (P)IC'tjes hiero?

[ Voor 18% gewijzigd door Verwijderd op 04-09-2003 21:05 ]

[den 150]

Ik zou beginnen met 'm extern te bouwen, niet te moeilijk maken in begin.
En wat moet je juist weten van pics? Ik ken er zelf niet veel van, maar er zijn genoeg sites die je vast en zeker kunnen helpen

[Verwijderd]

Extern of intern... verschil is minder groot dan je denkt
Maar ik ga hem sowieso eerst op een breadboard bouwen.
Het probleem is dat ik meer een softwareman ben... ik zou nog net een fancontroller kunnen bouwen, maar als er ICtjes bijkomen e.d. wordt het me al snel te lastig.

[LauPro]

Het protocol dat je wilt gaan maken lijkt dus een beetje op het Internet Protocol. Echter je vergist je in iets: dat is nl dat de 0 normaliter het netwerkadres is en dat is hier niet het geval. Daarnaast is de ether een shared medium dus in principe heeft het geen zin om iets te 'broadcasten', het is iig iets waar je wellicht later mee moet beginnen. Maar ik heb er een oplossing voor.

Maar dat je netwerkje > 200 van die krengen aankan is wel heel leuk, maar niet echt schaalbaar. Ik heb geen idee hoe snel die poort is op je 'TI' maar ik schat richting de 2400 bps. Stel dát je dat zou halen via de ether (hier heb ik geen idee van) dan zit je met 12 bps te rommelen (grofweg, natuurlijk veel, véél minder). Ik schat dat dat netwerk gewoon niet meer wil draaien. Het is niet voor niks dat bij IP sommige subnetten worden opgedeeld in subnetten om de zogenaamde 'broadcast-storms' in te dammen (en dat bij een switched netwerk, dit is dus een shared medium. De meeste WiFi AP's hebben ook een beperking van 30 clients voor zover ik weet).

Ik zou het systeem gaan bouwen voor maximaal 50 clients. En dan kan je ook nog wat leuks doen: broadcast domains (en daar heb je er dus nog 256 - 50 van). Een broadcast domain kan je zien als een apart 'kanaal'. Stel dat je met een chat aan de slag gaat: dan heb je bijv chatkanaal 1 t/m 10 en 1 staat dan gelijk aan #51 en 2 aan #52 etc (#n is het nummer dat je hebt). En je moet dan alleen instellen dat je het verkeer dat op #52 binnenkort ook voor jouw TI is.

Wat je je even moet afvragen is wat beter is; het protocol in je TI (ik noem het even zo) of extern in een soort modem. Voor zover ik weet is het maken van plugins vrijwel onmogelijk en ik zou dan ook voor de modem-optie gaan. Daarnaast is het beter om met een soort token-ring principe te werken, dan heb je iig gewoon een vaste bandbreedte en vrij weinig te doen met error-correction.

Er gaat dan dus een tellertje lopen van 1 tot 75. 25 van die domains is zat en #0 wordt dat het broadcast adres. Dat telletje gaat lopen zodra de TI merkt dat er niet meer TI's zijn. Ondertussen gaat hij elke 10 seconden 'advertisements' sturen op #0 (zo van: hallo ik ben hier zijn er nog meer ). De TI heeft dan ook automatisch #1. Dat versturen van die ads doet alleen #1, #1 is dus ook diegene die de boel coördineerd. De reden van de ads komt straks. #1 zet dus op #0 telkens een nummer (dus B1 t/m 75). Dan krijgt elke client een bepaalde tijd (fractie van een sec) de kans om iets terug te zeggen. Als het lukt om dat met 32 bits te regelen (dus 8 karakters, 1 voor adres en de rest voor de naam v/h kommando (het kan dus ook wel in 2 bytes, ik ga even uit van 4: #**| (#=nummer, **= commando, | = einde maar dan het eof-teken))).

Dat zou dus betekenen dat je in principe binnen 1 sec een 'cycle' af hebt, bij 4 bytes dus op z'n max 8 cycles/sec wat gelijk staat aan 125ms. Omdat de client ook nog wat terug moet zeggen (en dat moet 'ie heel snel doen) kan je dus 4 cycles/sec doen als er geen verkeer is. Zet de maximale waarde van een frame op 128 bytes, dan blijft het nog snel tov de rest. Je moet ook niet vergeten dat je bij 'token-ring' in principe een vaste bandbreedte hebt, dus ookal is er veel verkeer, iedereen heeft gewoon een vast aantal bandbreedte. Eventueel zou je die teller kunnen variëren, als er weinig clients zijn (stel 10) dat die dus van 1 tot 10 gaat ipv 1 tot 75, dat scheelt natuurlijk aanzienlijk.

Nu vraag je je natuurlijk af wat er gebeurt als er nog een #1 binnen bereik komt. Wellicht is het handig dat de #1 in zijn advertisements ook het aantal active clients meegeeft. Als een #1 dus een advertisement tegenkomt met meer active clients, dan geeft 'ie zegzelf over en stuurt een 'network brakedown' (oid ) waardoor iedereen in bereik zijn nummer verliest en onder het beheer valt van de #1 met meer clients.

Als de #1 vegvalt gebeurt er hetzelfde, er moet dan denk ik gewoon logisch bedacht worden dat #2 of #3 etc de leiding over neemt (de eerst beschikbare). Dus ook hier een 'NBD'.

Ik denk zelf dat het opnieuw instellen van die adressen totaal binnen 1 sec gefixt is. Een client wijst zich ook zelf een adres toe zodra hij merkt dat er niemand reageert op het eerstvolgende nummer. Zodra er twee clients met dezelfde adressen rondlopen geven ze hem allebei vrij en zoeken weer een nieuw leeg adres. Om deze mannier krijg je dus geen dubbelen en dat er geen verkeer nodig is om een adres uit te delen, dat gaat simpelweg geheel automatisch (je bent binnen een seconde opgenomen in het netwerk).

Dan wat voordelen/nadelen tov mijn 'token ring' idee en een 'standaard systeem'
'token ring':

• Iedereen heeft een vaste bandbreedte, eventueel met een variabele teller op te verhogen.
• Adressering gaat geheel automatisch en niet ten kosten van de bandbreedte
• Bij het uitvallen van #1 is het netwerk tijdelijk plat, ook als er twee #1'en bij elkaar komen waardoor de buitenste clients geen verbinding meer hebben. Dit betekend dus ook nieuwe nummering waardoor je wellicht met heel iemand anders aan het chatten bent (echter de broadcast domains lossen dit op)

'standaard systeem':

• Bandbreedte is minder naar mate er meer verkeer is, echter wel heel snel bij weinig clients.
• Adressering gaat ten kosten van de bandbreedte of moet handmatig worden ingesteld.
• Er kunnen dubbele nummers/adressen voorkomen

Dat was het wel zo'n beetje zoals ik er over dacht . Overigens denk ik niet dat dit echt gaat werken, als er al zo'n draadloos netwerk gaat komen (met een goede standaard) dan zal dit vanuit de fabrikant gebeuren. Wellicht voor sommigen hier interessant om naar een PDA te kijken .

[ Voor 3% gewijzigd door LauPro op 04-09-2003 21:28 ]

[Verwijderd]

Ik heb ook al nagedacht over het tokenring principe, maar het grootste probleem hierbij is dus wat je moet doen als er 1 calc plotseling uitvalt (bijv de #1).
Verder draait het netwerk gewoon op 160kbps, dus het netwerk draait een stuk sneller dan de rekenmachines zelf aankunnen. Daardoor zul je ook minder snel het 'netwerk verstopt'-effect hebben. Bovendien zie ik niet echt het probleem met het 'gewone netwerk' qua veel minder bandbreedte hebben bij veel calcs, aangezien alle radiomodules zijn uitgerust met collision avoidance, dus eerst wachten op een vrij moment om iets te gaan sturen.
Bij zo'n tokenring heb je altijd óf een server nodig die kijkt wie er aan de beurt is om zn zooi te sturen (maar ik wil een netwerk zonder server), of de rekenmachines moeten dat zelf gaan doen, maar dan heb je een probleem als 2 opeenvolgende calcs zichzelf afmelden.

Aangezien dat netwerk toch op een veel hogere snelheid draait dan die calcs aankunnen zal ook wat extra headerinfo niet zoveel uitmaken (zoals adressering). Over die broadcastnetwerken heb je zeker wel een punt, alhoewel dat wel moeilijk zijn om te implementeren (aangezien je ook bij meerdere broadcastnetwerken aangemeld moet kunnen zijn).
-edit-
Ook een byte afzender lijkt me handig.

Over dubbele adressen:
Ten eerste kijkt de rekenmachine gedurende een (paar?) seconde(n) welke rekenmachines zich allemaal op het netwerk bevinden, dat kan doordat iedere rekenmachine als hij gedurende een bepaalde tijd geen pakket heeft gestuurd een 'ik leef nog'-pakketje moet sturen.
Daarna kiest hij een van de nog vrije adressen, en begint hij zelf van die 'ik leef nog' pakketjes te sturen.
Mocht het nou toevallig zo zijn dat 2 calcs op precies hetzelfde moment aanmelden en hetzelfde adres kiezen is dat ook geen probleem; als een calc zijn eigen adres hoort als afzender (van al dan niet een 'ik leef nog pakketje') moet hij de inlogprocedure opnieuw doen.

@PDA:
Die mag je niet tijdens proefwerken gebruiken

[ Voor 16% gewijzigd door Verwijderd op 04-09-2003 22:04 ]

[Verwijderd]

Verwijderd schreef op 04 September 2003 @ 21:56:
[knip]Mocht het nou toevallig zo zijn dat 2 calcs op precies hetzelfde moment aanmelden en hetzelfde adres kiezen is dat ook geen probleem; als een calc zijn eigen adres hoort als afzender (van al dan niet een 'ik leef nog pakketje') moet hij de inlogprocedure opnieuw doen.

Het lijkt me slim dat als hij zich moet resetten(door het 'ik leef nog pakketje'), moet er eerst een RANDOM tijd worden afgelopen, doordat de 2 calcs allebij een verschillende aanmeldtijd hebben hierdoor kan je niet nog een keer een dubbel adres krijgen(hoop ik). Anders kan je in een loop raken bij het aanmelden.
De random tijd mag iets van 0,01 tot 1 seconde zijn. Hierdoor verwacht ik niet dat er nog een keer een dubbel adres te vinden is.

Ook zou het leuk zijn als er een bit bij komt voor 'ik was al eerder in dit netwerk' code. Die hoofdcode wordt uitgegeven door #1, als er dan een andere calc binnen het berijk komt met het zelfde nummer dan moet ook nog de hoofdcode gelijk zijn voordat je er in kan.

_{nee ik heb geen calc, behalve mn pda}

[Verwijderd]

@ 2 calcs met zelfde adres:
Maar 1 van de calcs (degene die zijn pakketje als laatst verzendt) zal detecteren dat er een dubbel adres is, aangezien die pakketjes ná elkaar worden gestuurd en nooit tegelijk.

En over die hoofdcode: zoals ik al zei wilde ik het een serverloos netwerk maken. Wat is trouwens het nut van die hoofdcode?

[MixingMastersM]

MewBie schreef op 03 September 2003 @ 14:19:
ik zie een heleboel mogelijk heden met zo'n syteem chatten tijdens een proefwerk ofzo

Haha wij wisselen altijd gewoon onze ti's uit in een onbewaakt moment. dat werkt ook ideaal. maar dit is ook heel wat. hier zie ik wel goud in! Voor de rest heb ik geen id hoe je zoiets zou kunnen doen. want chatten kan niet via het kabeltje, dus als het dan wel via het netwerk kan, dat zou echt ideaal zijn..wauw! Kom op mensen, wie heeft hier zinnige dingen over te zeggen? (Ik in ieder geval niet )

[ Voor 30% gewijzigd door MixingMastersM op 04-09-2003 23:01 ]

[den 150]

Als je met meerdere calcs gaat werken heb je zowieso een protocol nodig, ik zal morgen mijn boek van netwerken eens doorzoeken naar een geschikt protocol.
En low-level (hardware) protocol van de ti calcs is heel simpel, zal morgen wa links posten (nu slapen )

[LauPro]

Verwijderd schreef op 04 september 2003 @ 21:56:
Ik heb ook al nagedacht over het tokenring principe, maar het grootste probleem hierbij is dus wat je moet doen als er 1 calc plotseling uitvalt (bijv de #1).

Een oplossing heb ik toch al beschreven? De eerst volgende client wordt dan #1.

Verder draait het netwerk gewoon op 160kbps, dus het netwerk draait een stuk sneller dan de rekenmachines zelf aankunnen. Daardoor zul je ook minder snel het 'netwerk verstopt'-effect hebben. Bovendien zie ik niet echt het probleem met het 'gewone netwerk' qua veel minder bandbreedte hebben bij veel calcs, aangezien alle radiomodules zijn uitgerust met collision avoidance, dus eerst wachten op een vrij moment om iets te gaan sturen.

Je netwerk kan dan wel op 160 kbps draaien, echter moet je toch altijd op het antwoord van de ander wachten - dat gaat over die 'trage' lijn. Ik vraag me af of er (goedkope) IC's zijn die die snelheid aankunnen. Dan heb je ook nog is het probleem dat je dus die lijn moet emuleren oid, kortom; dat modem wordt nog slimmer dan die TI zelf, hoeveel kost zo'n ding ook alweer - zie je mijn punt .

Bij zo'n tokenring heb je altijd óf een server nodig die kijkt wie er aan de beurt is om zn zooi te sturen (maar ik wil een netwerk zonder server), of de rekenmachines moeten dat zelf gaan doen, maar dan heb je een probleem als 2 opeenvolgende calcs zichzelf afmelden.

Ik wil niet heel vervelend zijn maar een oplossing heb ik hiervoor al beschreven, daarnaast gaat de snelheid bij dat 'gewone' netwerk per client extra al domweg met de factor 2 omlaag. Bij een tokenring netwerk heb je helemaal geen server nodig oid, dat gaat juist vanzelf!

Wat is de prijs van die module overigens?

[ Voor 28% gewijzigd door LauPro op 04-09-2003 23:02 ]

[The Evil Brain]

offtopic:
dit wordt een nutteloze reactie (gooi m eventueel maar weg), maar ik wil alleen ff zeggen dat dit gewoon een cool topic is

[Verwijderd]

Hmm ja, die tokenring is toch redelijk moeilijk te programmeren denk ik...

@2400kbps:
Sorry, ik las over de 'k' heen
Maar volgens mij is die linkpoort nog minder dan 160kbps, als ik kijk naar hoe snel het programma's overzetten gaat (calc-calc en calc-pc). Maar natuurlijk kan ik het mis hebben

Dat bij een tokenring de snelheid met een factor 2 omlaag gaat van wat het netwerk aan zou kunnen begrijp ik (de #1 moet immers steeds een pakketje sturen om aan te geven wie er aan de beurt is), maar volgens mij moet dat bij het IP-achtige protocol niet het geval zijn; je hebt geen zendtijd gebruikende tokens en er zijn geen collisions; je stuurt alleen een byte afzender, een byte bestemming, en eventueel nog een byte pakkettype extra. Alleen de afzenderbyte zou onnodig zijn bij een tokenring.

-edit-
Mja ik zat me ook al zorgen te maken over de kosten... maar ze zijn vast wel door te verkopen aan de volgende generatie scholieren (die dezelfde rekenmachine moeten aanschaffen)

-edit2-
Die modules kosten $69,- per stuk zie ik net
Iemand een goedkoper alternatief?
Als die geen collision detection hebben maakt het niet zo heel veel uit, dan passen we gewoon LauPro's idee toe
Error checking zou eventueel ook nog softwarematig kunnen, als dat nodig is

-edit3-
Deze ziet er redelijk betaalbaar uit:

These modules will suit one-to-one and multi-node wireless links in applications including car and building security, EPOS and inventory tracking, remote industrial process monitoring and computer networking. Because of their small size and low power requirements, both modules are ideal for use in portable, battery-powered applications such as hand-held terminals.

Enige nadeel is dat ze maar 20kbps aankunnen... maar waarschijnlijk wordt er toch niet veel meer mee gedaan dan een beetje chatten en daarvoor is 20kbps denk ik wel genoeg...

[ Voor 49% gewijzigd door Verwijderd op 05-09-2003 00:53 ]

[Meulugar]

MixingMastersM schreef op 04 September 2003 @ 22:53:
[...]

want chatten kan niet via het kabeltje, dus als het dan wel via het netwerk kan, dat zou echt ideaal zijn..wauw! Kom op mensen, wie heeft hier zinnige dingen over te zeggen? (Ik in ieder geval niet )

chatten kan wel via het kabeltje. alleen dan wel half duplex tenminste zo is hetprogje geschreven. dat je eerst op het antwoord van de ander moet wachten.

[LauPro]

69 $ zou nog wel te doen zijn. Een tijdje terug heb ik in de Conrad-gids een antenne gezien die je zo op de C-Control aan kon sluiten. Als dat ding aan een C-Control kan dan gaat dat natuurlijk ook aan een ander vergelijkbaar IC, echter is de C-Control imo wel eenvoudige te programmeren , het probleem is alleen dat het geval wat groot gaat worden , maargoed. Je zou natuurlijk dat ding in je broekzak kunnen doen, en dat kabeltje met het motto 'kabel naar accu pack' kunnen verkapselen .

Allereerst zou ik is proberen om je TI's in een wired netwerk te hangen om te kijken of dat protocol überhaupt wel lukt. Ik moet wel zeggen dat die C-Control als modem nieteens zo'n gek idee is, wel wat kostbaar maarja; dan heb je ook wel wat.

[BOOTZ]

MixingMastersM schreef op 04 September 2003 @ 22:53:
... want chatten kan niet via het kabeltje, dus als het dan wel via het netwerk kan, dat zou echt ideaal zijn ...

kan wel via het kabeltje, ik heb ooit es een progje geschreven (gewoon in ti-basic) die dat kan, en realtime

een ti-netwerk is een leuk idee, maar ik denk het e.e.a. toch iets te prijzig wordt voor de meeste mensen, waardoor meteen de noodzaak van een netwerk met 50 nodes niet zo groot meer is

[Verwijderd]

LauPro schreef op 05 September 2003 @ 11:57:
69 $ zou nog wel te doen zijn. Een tijdje terug heb ik in de Conrad-gids een antenne gezien die je zo op de C-Control aan kon sluiten. Als dat ding aan een C-Control kan dan gaat dat natuurlijk ook aan een ander vergelijkbaar IC, echter is de C-Control imo wel eenvoudige te programmeren , het probleem is alleen dat het geval wat groot gaat worden , maargoed. Je zou natuurlijk dat ding in je broekzak kunnen doen, en dat kabeltje met het motto 'kabel naar accu pack' kunnen verkapselen .

Allereerst zou ik is proberen om je TI's in een wired netwerk te hangen om te kijken of dat protocol überhaupt wel lukt. Ik moet wel zeggen dat die C-Control als modem nieteens zo'n gek idee is, wel wat kostbaar maarja; dan heb je ook wel wat.

Mwah, $69 voor alleen maar het moduletje gaat toch een beetje boven mn budget, en ik denk dat veel van mn klasgenoten daar net zo over denken (de hele rekenmachine kostte een tientje meer via school)
Wat is C-Control precies?
En gaat het denk je lukken met die tweede module die ik postte?

Kabeltje-naar-accupack-smoes: Denk niet dat het erg geloofwaardig overkomt als je calc het nog doet als je het kabeltje eruit trekt

[ Voor 12% gewijzigd door Verwijderd op 05-09-2003 14:23 ]

[DiLDoG]

zorg dat alle componenten ook SMD versie hebben, dan kan je hem eventueel als alles werkt op een printje gooien en *IN* je ti bouwe

[LoBbY_1]

heel leuk, maar wat zou je maximale afstand zijn op die ferquentie? En ik neem aan dat die module ook wel het een en ander zal gaan snoepen.....Regel je dat dan via externe voeding? (batterijen in je kastje) of gewoon via de batterijen die in de TI zitten? Nadeel is natuurlijk ook als je een server/client id gaat maken dat als er TI's op een iets te grote afstand zitten lastig gaan doen Misschien zou je om de paar nummers in je protocol een "accespoint" kunnen maken? die dan zeg maar verder alles doorzenden.
bijvoorbeeld
uitgaande van MAX 50 TI's 1=ACpoint 10=ACpoint 20=ACpiont enz tot 50

Kan natuurlijk ook zijn dat dit de grootste onzin is je hier uitgekraamd word

[ Voor 3% gewijzigd door LoBbY_1 op 05-09-2003 16:42 ]

[frickY]

Wow wat n plannen

Ik weet nog dak in 4HAVO een chat-proggie had geschreven om met de gozer naast me te praten als iedereen zn bek moest houden...
Dat was nog een heel gedoe, omdat het ontvangen-gedeelte van het ding niet echt geweldig is. Dus dit moet helemaal eng gaan worden

[Verwijderd]

frickY schreef op 05 september 2003 @ 20:08:
Wow wat n plannen

Ik weet nog dak in 4HAVO een chat-proggie had geschreven om met de gozer naast me te praten als iedereen zn bek moest houden...
Dat was nog een heel gedoe, omdat het ontvangen-gedeelte van het ding niet echt geweldig is. Dus dit moet helemaal eng gaan worden

De PIC maakt het juist makkelijker omdat je een extern buffer hebt waar je in kunt schrijven en uit kunt lezen wanneer je maar wilt

[wdekreij]

Uhm, jullie hebben het voornamelijk over de "netwerkconfiguratie", maar hoe hadden jullie de volgende dingen in gedachten:

Word het in of extern? Bij een rep of tentamen (en ik neem niet aan dat hij op het werk oid word gebruikt zal toch zijn op school zijn "voor het goede doel" ) Als er dan zo'n kastje aanzit, gaat het lichtelijk opvallen

Als hij continu moet scannen ed tijdens dat je een link wilt maken, kan het dan niet zijn dat de batterij duur dan nogal naar beneden gaat?

Ennuhm.. Ik houd mij zwaar hard aanbevolen als tester Ik wil ook graag helpen maar ik kan helaas niet zoveel waarmee ik jullie van dienst kan zijn ben ik bang

[Verwijderd]

wdekreij:
Het wordt ingebouwd, daarom wordt het waarschijnlijk prutswerk met SMD componentjes. Als het alleen extern kan ga ik sowieso niet door met dit project.
Verder is het eigenlijk alleen het verzenden wat (naar verhouding) veel batterij verbruikt, maar dat doet hij maar heel af en toe, dus zal dat nog wel meevallen. Hij gaat niet actief scannen. De bedoeling is ook om hem op een of andere manier aan en uit te kunnen zetten.

[Yoeri]

Wat mij eerst zou interesseren is hoe je extra geheugen in dat TI 83 ding krijgt

als je zelf protocollen en dergelijke gaat schrijven blijft er volgens mij namelijk niet zoveel plaats meer over in dat geheugen van 28k

* Yoeri is best tevreden met z'n zelfgemaakt kabeltje tussen parallelle poort pc en rekenmachine... cursusje overtypen op pc is nu ook niet zoooo lastig

[LauPro]

Als het intern moet kan je het denk ik haast wel vergeten. Gezien de afstand is er toch wel een extra accu nodig die hoogstwaarschijnlijk een 5V moet gaan leveren, zo'n accu zal wel niet bestaan dus wordt dat iig iets van 4 x lady oid. Ik denk dat je het met SMD hooguit in PCMCIA-formaat kan krijgen, processoren zijn toch wel redelijk groot in voor SMD volgens mij erg duur. Daarnaast moet je wel de mogelijkheid hebben om je printje te bakken.

Daarnaast komt er bij SMD veel meer kijken, als ik jou was zou ik het eerst is op wat grotere schaal proberen met bijv. die C-Control.

C-Control is een processor (http://www.c-control.de) die je kan programmeren in Basic, dat maakt het je een stuk makkelijker. Hij is wel wat prijzig maar voor dit soort experimenten eigenlijk perfect. Om de 20ms doet hij een commando (intern) dus op zich wel redelijk snel. En heeft een interface die (als die TI een beetje standaard-gericht is) direct aan te sluiten is op je TI. Ik heb verder geen ervaring met die antenne maar wat ik wel weet dat het relatief goedkoop was om dat te doen (denk aan een tiental euro's).

Infrarood is trouwens ook een optie, als je een krachtige led neemt dan kan er best wel wat tussen zitten, daarnaast zou je in alle 4 de hoeken van je TI zo'n led/ldr kunnen plaatsen waardoor je optimaal 'bereik' hebt.

En als je die antenne toch intern wil hebben dan kan je geen extra processor gebruiken. Dan zul je alle berekeningen door die TI moeten laten doen: vergeet dan de grootschaligheid en maak een programma waarmee je 2 á 3 van die dingen kan laten communiseren.

[ Voor 9% gewijzigd door LauPro op 06-09-2003 00:06 ]

[wdekreij]

als je intern iets wilt doen, kan het dan niet dat we de rekenmachien dikker maken, laat maar zeggen?.. Dus dat je hem over de gehele lengte bijv. 3 mm dikker maakt, of is dat niet genoeg? Dat ziet een leraar dan toch niet

Zo'n kastje ernaast lijkt me wel een béétje opvallend

[frickY]

Ik had bij een afsluitende toets alle elektrische schema's in mn rekenmachine getekend (had wat avondjes vrij ervoor ) en het werd ook absoluut niet maf gevonden dat ik een rekenmachine gebruikte bij het tekenen van een schakeling.
Als je een flatkabeltje gebruikt ipv het standaard draadje, en het zendertje in je etui ofzo propt.. zal het tijdens gewone toetsen wel meevallen met hoe t opvalt

[Verwijderd]

Over een oppervlak van 6x6cm is iets minder dan een cm ruimte over... dat zou toch wel genoeg moeten zijn? Ik bedoel, zelfs met HMD componenten.
De batterijen in het ding leveren in totaal 6v, dus gooi er een weerstandje tussen en het zou goed moeten zijn (tenzij hij echt precies 5v nodig heeft, maar ik denk dat dat niet nodig is). De antenne hoeft niet meer te zijn dan een spoortje op de PCB met een Ctje om de antennelus te sluiten; die antenne kan het beste overweg met metalen onderdelen in de buurt.
Over die C-Control: het ziet er erg aantrekkelijk uit op die site, maar het ziet eruit of het gewoon een µc is waar ze een C-Control programma op hebben gegooid die basic naar opcodes vertaalt. Er zitten gewoon téveel mogelijkheden op die we toch nooit gaan gebruiken voor dit project
Om het ding met een PIC in elkaar te gaan zetten is wel moeilijker, maar het resultaat is veel efficiënter en goedkoper

[ Voor 3% gewijzigd door Verwijderd op 06-09-2003 01:39 ]

[Rostvertol-Mil]

Verwijderd schreef op 05 September 2003 @ 20:46:
[...]


De PIC maakt het juist makkelijker omdat je een extern buffer hebt waar je in kunt schrijven en uit kunt lezen wanneer je maar wilt

als je de functie send en get uit ti-basic gebruikt komt de variabele ook in een soort buffer (ti noemt het een CBL) , dit zit als het ware tussen de 2ti's in, je kunt dus niks rechtstreeks naar een andere ti zenden. je zend alleen naar et CBL, daar lich de data lekker te wachten tot het opgehaald wordt met de functie get.

(getCalc haalt wel meteen een variabele op van een andere TI)

maar is zo'n CBL princiepe niet iets voor een protocol:
pakketje wordt naar et "CBL" gestuurd, headers worden wel meteen doorgestuurd naar de TI('s) , als de desbetreffende TI de header ontvangt haalt hij et pakketje op uit et CBL, en stuurt meteen een confirm naar de afzender (zo heb je meteen een soort collision detection).
Pakketjes kunnen ook naar meerdere pc's gestuurt worden in 1 keer, 1 keer senden naar CBL en andere ti's kunnen het er afhalen, scheelt meteen weer bandbreedte


naja, errug veel verstand van een protocol heb ik niet, tis iig maar een idee

[ Voor 3% gewijzigd door Rostvertol-Mil op 06-09-2003 22:02 ]

[Verwijderd]

Rostvertol-Mil:
De 'driver' wordt in assembler geschreven, dus aan BASIC functies hebben we niet zoveel. Daarom vraag ik me af waar in het geheugen dat buffer zich bevindt, want er staat niets over in TI's geheugendocumentatie (met assembler heb je volledige toegang tot het gehele geheugen).

[DiLDoG]

zoals ik eerder zei, neem componenten die zowel in SMD als DIP verkrijgbaar zijn, dan kan je met dipjes lekker ontwerpen en kutten, en als t dat allemaal werkt dan bestel je ergens een printje en gooi je die smdtjes erop, ik heb mijn 83plus even opengemaakt en er is hier en daar nog wel ruimte denk ik

[den 150]

Ff opmerking: de chip die in de 1e post staat (die Radiometrix) heeft GEEN collision avoidance, wel carrier detect.
De chip verkrijgbaar bij velleman heeft dit ook, in tegenstelling tot wat hier ergens beweerd werd. Ik wil gewoon maar zeggen dat die velleman chip een volwaardig alternatief is (en waarschijnlijk gemakkelijker verkrijgbaar) dan die Radiometrix. Over de prijs heb ik geen idee, maar ik zal na het weekend eens gaan horen in velleman verdeler.

En dan nu over het protocol.
Ik ga uit van een extra chip (bijvoorbeeld een pic) tussen de calc en de transceiver die het verkeer aankan. Voor de gemakkelijkheid noem ik 'm pic, maar kan evengoed iets anders zijn.
Als je met meerdere calcs wil communiceren zonder enige vorm van server of acces point dan ga je volgens mij moeten werken met vast gekozen adressen die in de pic zit (en die je niet kan veranderen zonder pc). Je kan eventueel wel je naam aan het adres koppelen. Als de calc iets wil zenden dan buffert de pic dit en gaat die kijken of iemand aan het zenden is. Is dat niet zo dan zendt hij gewoon, is dat wel zo dan wacht de pic een random tijd, en kijkt hij opnieuw. (basicly ethernet principe).
Een ingewikkelder systeem is niet nodig (zelfs met 20+ clients heb je nog niet zoveel traffic, het blijft tenslotte maar een ti calc), en als je bijvoorbeeld wilt gaan werken met slotted aloha dan heb je al tijdsynchronisatienodig (en dus server/access point).

Naar mijn menig moet je niet alleen een broadcast chat hebben, maar ook de gewone link functie zodat je eventuele programma's ofzo kan uitwisselen. Via een broadcast pakketje kan je de zelf-opgegeven namen van iedereen opvragen zodat je een destination-adres kan kiezen. Gerichte non-broadcast pakketjes kunnen op die manier geacknowledged worden om error-vrij te werken. Error checking (bv door collision) gebeurt dan door een checksum berekend door de pic. Hierdoor zal je in een druk netwerk wel wat meer moeten bufferen omdat je telkens moet wachten op acknowledge, tenzij je met volgnummers werkt zodat je 1 bepaald pakketje opnieuw kan zenden.
Bij gerichtje pakketjes moet de zender eerst wel toestemming vragen aan de ontvanger (dit doen de pics), omdat de ontvanger eventueel niet is afgestemd op de zender. Als dit niet zo is houdt de pic een error code bij die de calc kan uitlezen (en evt. vertalen naar verstaanbare text). Een error kan je eventueel signaliseren met een apart ledje.

Ik heb voorlopig het probleem van niet-zichtbare clients buiten beschouwen gelaten, omdat je dan moet relayen. Dit zou het protocol wat ingewikkelder maken en dit lijkt mij ook overbodig.

Na consultatie van mijn favoriete netwerken boek (Computer Netwerken, door Andrew S. Tanenbaum, uitgever Academic Service, wij gebruiken dit boek op school als onderdeel van de netwerkencursus) lijkt dit me de beste oplossing. Ik weet dat het een mengeling is van een aantal protocollen en principes, maar dit is een unieke situatie waardoor je niet zomaar een bestaand protocol kan gebruiken.

Als iemand nog bedenkingen of opmerking heeft, post maar. Het kan natuurlijk altijd dat ik een stommiteit heb begaan of over het hoofd gezien, dat gebeurt wel meer bij mij

[Verwijderd]

Ingebakken adressen lijkt me niet echt praktisch... waarom zou het niet kunnen op de manier die ik hierboven beschrijf (luisteren welke vrij zijn, eentje uitkiezen, als je je eigen adres hoort opnieuw luisteren welke vrij zijn & eentje uitkiezen)?
En zoals je kunt lezen wilde ik er ook een bestemmingbyte in bakken zodat je niet alleen kunt broadcasten
Die ACKs en checksums lijken me wel een goed idee.

[Rostvertol-Mil]

Verwijderd schreef op 07 September 2003 @ 01:24:
Rostvertol-Mil:
De 'driver' wordt in assembler geschreven, dus aan BASIC functies hebben we niet zoveel. Daarom vraag ik me af waar in het geheugen dat buffer zich bevindt, want er staat niets over in TI's geheugendocumentatie (met assembler heb je volledige toegang tot het gehele geheugen).

ik weet, de mogelijkheden van ti-basic zijn errug beperkt

[den 150]

Verwijderd schreef op 07 september 2003 @ 15:10:
Ingebakken adressen lijkt me niet echt praktisch... waarom zou het niet kunnen op de manier die ik hierboven beschrijf (luisteren welke vrij zijn, eentje uitkiezen, als je je eigen adres hoort opnieuw luisteren welke vrij zijn & eentje uitkiezen)?

Als je op een geregeld tijdstip je eigen adres uitzend genereert dit een hoop traffic wat volgens mij overbodig is; je hebt bovendien veel kans op collisions wat op zich nog meer traffic genereert. Aangezien dit een broadcast is zou het acknowledgen hiervan nog meer traffic genereren, en dit is echt wel nodig aangezien je je geen foute adressen kan permiteren.
Nog een mogelijk probleem in de volgende situatie: Je hebt 3 calcs A, B, en C. A ziet C niet en omgekeerd, maar iedereen ziet B (vanwege zendbereik). Als A het adres van C inneemt (dit gaat want hij ziet het adres van C niet) en B stuurt iets naar C dan antwoordt zowel A als C.

Vaste adressen zijn heel gewoon, elke nic en elke gsm hebben een vast uniek adres (mac bij nic, en imei bij gsm). Als je die gegevens enkel opvraagt wanneer het nodig is (om de namen en adressen op te vragen zodat je weet wie wie is) bespaar je serieus wat bandbreedte (en de pic kan zo'n rondvraag ook cachen ook al is ie niet voor hem bedoelt).

Imo is een dynamisch adres een goede oplossing als je een server gebruikt, maar zonder server kan je je beter baseren op vaste adressen. Bij vaste adressen kan je bovendien de adressen van je classmates al 'hardcoden' in je ti zodat je ze niet eens meer moet opvragen.

[EL_Loco]

den 150 schreef op 07 September 2003 @ 16:22:
[...]


Vaste adressen zijn heel gewoon, elke nic en elke gsm hebben een vast uniek adres (mac bij nic, en imei bij gsm). Als je die gegevens enkel opvraagt wanneer het nodig is (om de namen en adressen op te vragen zodat je weet wie wie is) bespaar je serieus wat bandbreedte (en de pic kan zo'n rondvraag ook cachen ook al is ie niet voor hem bedoelt).

Imo is een dynamisch adres een goede oplossing als je een server gebruikt, maar zonder server kan je je beter baseren op vaste adressen. Bij vaste adressen kan je bovendien de adressen van je classmates al 'hardcoden' in je ti zodat je ze niet eens meer moet opvragen.

dan neem je gewoon (uitgaande van dat je opschool zit) je leerlingen nummer.
tenzij dat te lang is natuurlijk.
-edit-
achwat, niet moeilijk doen, iedereen van te voren een eigen nummer geven, op internet een overzichtje plaatsen, iedereen progt z'n eige nummertje in,
en gaan.....

[Rostvertol-Mil]

den 150 schreef op 07 September 2003 @ 16:22:
[...]


Als je op een geregeld tijdstip je eigen adres uitzend genereert dit een hoop traffic wat volgens mij overbodig is; je hebt bovendien veel kans op collisions wat op zich nog meer traffic genereert. Aangezien dit een broadcast is zou het acknowledgen hiervan nog meer traffic genereren, en dit is echt wel nodig aangezien je je geen foute adressen kan permiteren.
Nog een mogelijk probleem in de volgende situatie: Je hebt 3 calcs A, B, en C. A ziet C niet en omgekeerd, maar iedereen ziet B (vanwege zendbereik). Als A het adres van C inneemt (dit gaat want hij ziet het adres van C niet) en B stuurt iets naar C dan antwoordt zowel A als C.

Vaste adressen zijn heel gewoon, elke nic en elke gsm hebben een vast uniek adres (mac bij nic, en imei bij gsm). Als je die gegevens enkel opvraagt wanneer het nodig is (om de namen en adressen op te vragen zodat je weet wie wie is) bespaar je serieus wat bandbreedte (en de pic kan zo'n rondvraag ook cachen ook al is ie niet voor hem bedoelt).

Imo is een dynamisch adres een goede oplossing als je een server gebruikt, maar zonder server kan je je beter baseren op vaste adressen. Bij vaste adressen kan je bovendien de adressen van je classmates al 'hardcoden' in je ti zodat je ze niet eens meer moet opvragen.

als je er nou een dipswitch op zet waar je het adres mee kan maken 6x2 dipswitch is genoeg voor 64 adressen

[Bl@ckbird]

Met die Carrier Detect kan je kan je logica aansturen. Je kan zo een filter bouwen die alleen signalen doorlaat die van Radiometrix modules af komen. (En niet je zusje met wireless koptelefoon...)

Mischien is het handig om eerst ff te kijken wat er over zo'n linkabeltje fietst. Maak hiervoor een breakout-kabeltje, die je tapt met een Scoop. Schrijf een programmatje waarmee je van te voren weet wat voor een bitpatroon je gaat sturen. Je krijgt dan inzicht in de bitrate en spanningsniveau's die je aan de PIC wil aanbieden. En of dit juist is met de specs van de PIC. Zie ook:



Dynamisch adressen toewijzen wordt denk ik te complex. Je kan wel een programmatje schrijven waarmee het adres van een station kan wijzigen. De gebruiker vult een unieke naam in. (Bijv. -Blackbird- ) Het geschreven Ti programma zet hier een unieke bitreeks voor en zend dit naar de PIC. De PIC ontvangt het frame met de naam (Wat dan ook een bitreeks is) En gebruikt dit als adres.
Zo'n frame ziet er ongeveer zo uit en bestaat naast de gebruikelijke data:

code:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Unieke Bitreeks Adreswijziging +     Naam in bits (=Data)    +                              
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Dit zit dus tussen PIC en Ti83.
De grootte van bovenstaand frame is altijd even groot. Zo weet de PIC hoeveel bits hij voor een adreswijziging moet inklokken.

Tussen PIC en PIC ziet het er ongeveer zo uit:

code:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+   A   +   B   + C +                 D                 +  E  +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

A
Adres ontvangende station.
(Of adres ALL voor een broadcast)

B
Adres zendende station.

C
Acknowledge - Frame is goed /niet goed ontvangen. (1 of 0)
1 Je kan een bevestiging sturen. (Dataveld is 0)
2 Je kan tegelijk met de bevestiging data sturen. Je moet dan idd. met frame nummers gaan werken wat het weer complexer maakt.

D
Te verzenden data.

E
Checksum.

Een andere optie is om het netwerk uit te breiden en er PC's in te hangen. Communicatie gebeurt hetzelfde als bij de Ti variant, maar voor deze versie heb je een PIC nodig met een UART. Dit is een seriële interface om te kletsen met de PC.
Het voordeel hiervan is dat je alleen de initialisatie moet regelen. (Baudrate enz.)

Dit is op een PIC zonder UART ook wel te regelen, maar dan heb je extra chips nodig (MAX232) en je timing moet precies goed zijn.

Je kan natuurlijk ook voor alle station een PIC met UART aanschaffen. Of je hem nu gebruikt of niet.

[EL_Loco]

-Blackbird- schreef op 07 September 2003 @ 23:10:
[snip]heelverhaal[/snap]

Een andere optie is om het netwerk uit te breiden en er PC's in te hangen. Communicatie gebeurt hetzelfde als bij de Ti variant, maar voor deze versie heb je een PIC nodig met een UART. Dit is een seriële interface om te kletsen met de PC.
Het voordeel hiervan is dat je alleen de initialisatie moet regelen. (Baudrate enz.)

Dit is op een PIC zonder UART ook wel te regelen, maar dan heb je extra chips nodig (MAX232) en je timing moet precies goed zijn.

Je kan natuurlijk ook voor alle station een PIC met UART aanschaffen. Of je hem nu gebruikt of niet.

een uart is een leuk dingetje, maar ik heb in de conrad catalogus zitten zoeken, maar van de prijzen wordt je ook niet helemaal vrolijk

[Rein_stein]

bestel m in duitsland bij www.reichelt.de issie al de helft goedkoper (meestal)

[Bl@ckbird]

Haco schreef op 08 September 2003 @ 07:04:
een uart is een leuk dingetje, maar ik heb in de conrad catalogus zitten zoeken, maar van de prijzen wordt je ook niet helemaal vrolijk

't Is ook een optie. Uit de datasheet van de PIC 16F87/88:

Addressable Universal Synchronous
Asynchronous Receiver Transmitter
(USART/SCI) with 9-bit address detection:
RS-232 operation using internal oscillator
(no external crystal required)

Ze zijn ook te bestellen bij Microchip zelf.
Overzicht PIC familie

[den 150]

Pics kan je (beperkt) gratis krijgen op http://samples.microchip.com
ff registreren en je kan 5 chips bestellen, max, 3 dezelfde. Je zou ook meerdere orders kunnen doen, maar dat heb ik nog niet geprobeerd

[Verwijderd]

Misschien is i2c een optie?
Dit is een super simpel protocol.
Een is de master en die gaat de slaves bijlangs.
Dit in combinatie met een zender ontvanger.

Onderstaande link is van een super simpele fm zender.
http://tacashi.tripod.com/elctrncs/smplfmtr/smplfmtr.htm

[samo]

* Kick *

Ik heb hier al een tijdje niks van gezien, terwijl het een ontzettend interessant onderwerp is...

Even wat feedback tot nu toe:
CBL is een apparaat dat je op de TI aansluit om sensoren op aan te sluiten... Die slaat inderdaad info op, en stuurt dit naar de rekenmachine. Zo'n apparaat is best groot (2x zo groot als een 83+) dus dat is denk ik niet wat je zoekt...

Verder ben ik erg benieuwd of er al iets bereikt is!!! :-)

[mentalmadnizz]

Het chatprog moet inderdaad in assembly geschreven worden. basic zuigt.
mijn chat programma, toendertijd in basic:

kies server of client
typ naam in: voor server wordt str1 gebruikt, voor client str2
druk op enter als op allebei de rekenmachines de naam is ingevoerd
dan wordt er met het "Get"commando de string uit de andere rekenmachine opgehaald
dan komt er een venstertje met str1 en str2 zijn aangemeld
dan volgt het "horiz"commando, dit zorgt ervoor dat het scherm uit een grafisch gedeelte en een text gedeelte wordt verdeeld
dan begint het chatten, door bepaalde strings uit de rekenmachines te halen. dit had als gevolg dat je pas nieuwe berichten kon ontvangen als je zelf iets verzond. dit werkte dus niet. wat wel leuk was was de stop en de block functie. als block werd ingetypt en de andere rekenmachine ontving dit, kwam het volgende stuk code:

code:

if  Str4="BLOCK"
Go To 0 (dus de thetis,[ALPHA-3])

en die thetis bestond uit de commando's:
"full"voor het stoppen van horiz, dus dat het scherm in tekstmodus kwam
"stop" (lijkt me duidelijk)
als je stop intypte gebeurde hetzelfde, maar dan op je eigen rekenmachine.

ik heb het programma nog steeds, maar ik gebruik het niet meer. het kabeltje is ook veel te kort....
anywayz, ik wil het programma best testen, en als ik assebly ga leren wil ik ook wel kijken of ik wat kan programmeren. het lijkt me iig wel een vet project.

edit: op deze manier kun je dus ook draadlzoe LCD's maken!!!
gewoon die IC gebruiken voor de datalijnen enzo.... sweeet

[ Voor 7% gewijzigd door mentalmadnizz op 07-11-2003 22:14 ]

[samo]

*kickje*
Texas Instuments heeft nu een apparaat voor draadloze verbindingen. Ik heb het nu mogen testen en het is best leuk.
link: http://education.ti.com/u...or/features/features.html
Het werkt alsvolgt: een 'docent' heeft een basis unit aan een windows XP bak hangen. Er zijn dan nog draadloze netwerk hubs die tot 4 rekenmachine's aangesloten krijgen (met kabeltje). De netwerkhub is groot (heeft een behoorlijke batterij) en er zijn nog geen apps om elkaar mee te vinden en dus communicatie tussen rekenmachine's te starten.
Het systeem is bedoeld om veel apps tegelijk over te zetten (en daar ga ik het voor gebruiken ook) en om als docent te kunnen zien wat lln doen.

Het geen wat je wilt is dus mogelijk. Echter de navigator is duur. Erg duur. Hoe het netwerk word samengesteld weet ik niet, of dat via de pc geregeld word of niet. De prijs van een klaslokaalset navigators ligt ergens rond de 2000 euro...

Ik ben benieuwd of jullie het goedkoper kunnen (en nog willen)

[Reinstein]

Als je gebuik gaat maken van PIC (goed idee) je hebt dan een programmer nodig om die dingen te programeren:

Een JDM-programmer is eenvoudig te bouwen. [ http://www.jdm.homepage.dk/newpic.htm ]
Software: ICprog [ http://www.icprog.com ]

Ik gebruik dit zelf ook om PICs te programeren.

Programmeertalen voor PICs
* PICbasic - dit is basic, eenvodig te leren, zitten een hoop standaart fucties in, nadeel is dat je voor de compiler moet betalen. [ http://www.picbasic.co.uk/ ]
* JAL - deze taal heeft een gratis compiler. [ http://www.voti.nl/jal/ ]

Er zijn tevens compilers voor C.
Of je kunt het in Asambly doen.

Voor radio comunicatie zou ik 433MHz modules gebruiken, de Conrad verkoopt zender + ontvanger voor € 14.95

succes er mee