Hi, 

I want to know does TOSSIM model collisions. I have been studying the 
UscGainInterferenceModelC.nc, When I run my application, I get lost packet 
indications due to many reasons like signal strength is below the threshold or 
ambient noise is too much etc or the node has concurrently received a packet 
with stronger signal strength. 

My question is what happens when there are more than one transmitters and all 
send the packets at the same time. Do we have to check the packet metadata when 
we send the packets, and then when we receive them or get some loss indication 
to make sure something went wrong ? 

Any help will be much appreicated. 


Regards, 



[EMAIL PROTECTED] wrote: Send Tinyos-help mailing list submissions to
 tinyos-help@Millennium.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit
 https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

or, via email, send a message with subject or body 'help' to
 [EMAIL PROTECTED]

You can reach the person managing the list at
 [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tinyos-help digest..."


Today's Topics:

   1. Re: (yet another) Question about signal (Michael Schippling)
   2. Micaz and Telosb (Abdullah Kadri)
   3. Re: (yet another) Question about signal (Philip Levis)
   4. javacomm version 3 on Linux Ubuntu - serial port not
      receiving data (Miguel ?ngel ?MrNet?)
   5. Re: (yet another) Question about signal (Michael Schippling)


----------------------------------------------------------------------

Message: 1
Date: Wed, 14 Nov 2007 11:05:08 -0700
From: Michael Schippling 
Subject: Re: [Tinyos-help] (yet another) Question about signal
To: Michiel Konstapel 
Cc: tinyos-help@Millennium.Berkeley.EDU
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I guess if I took the time to read and understand all the NESCC design/doc,
rather than wasting it on trying to make my own projects work, I wouldn't
be asking so many seemingly redundant questions. I expect the whole thing
has to do with using "async" as a flag to force race-condition evaluation,
which then blossomed into a chain of fix-the-boundary-cases keywords.

thanks for the answer
MS


Michiel Konstapel wrote:
>> OK, good. Then another stupid question: "signal" == noop?
> 
> Not a stupid question at all, because yes, that's basically true. If you
> look at the generated C code in build/$PLATFORM/app.c you'll see both "call
> Foo.bar()" and "signal Foo.bar()" get turned into an ordinary C function
> call.
> 
> Here's an example taken from Blink:
> 
> nesC:
> event void Timer0.fired()
> {
>   call Leds.led0Toggle();
> }
> 
> C:
> static inline  void BlinkC$Timer0$fired(void)
> {
>   ;
>   BlinkC$Leds$led0Toggle();
> }
> 
> The code that fires the timer event from VirtualizeTimerC is a bit messy
> because of the generic components involved, but eventually firing the event
> just turns into a regular call to BlinkC$Timer0$fired().
> 
> 
> HTH,
> Michiel


------------------------------

Message: 2
Date: Wed, 14 Nov 2007 13:05:56 -0500
From: Abdullah Kadri 
Subject: [Tinyos-help] Micaz and Telosb
To: tinyos-help@millennium.berkeley.edu
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

Dear All,

I am in the process of buying a system from Crossbow and want to know the
key differences between both of micaz and telosb boards. Can anyone tell me
about this please?

Thanks a lot.

 

Abdullah Kadri, P.Eng., Ph.D. Candidate 
The University of Western Ontario 
Department of Electrical and Computer Engineering 
Phone: (519) 661-2111 ext. 81271

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20071114/baa4b9a7/attachment.html

------------------------------

Message: 3
Date: Wed, 14 Nov 2007 10:22:32 -0800
From: Philip Levis 

Subject: Re: [Tinyos-help] (yet another) Question about signal
To: Michael Schippling 
Cc: tinyos-help@millennium.berkeley.edu
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed


On Nov 14, 2007, at 10:05 AM, Michael Schippling wrote:

> I guess if I took the time to read and understand all the NESCC  
> design/doc,
> rather than wasting it on trying to make my own projects work, I  
> wouldn't
> be asking so many seemingly redundant questions. I expect the whole  
> thing
> has to do with using "async" as a flag to force race-condition  
> evaluation,
> which then blossomed into a chain of fix-the-boundary-cases keywords.

Not at all. The async keyword wasn't introduced until TinyOS 1.1.

Phil


------------------------------

Message: 4
Date: Wed, 14 Nov 2007 19:26:09 +0100 (CET)
From: Miguel ?ngel ?MrNet? 
Subject: [Tinyos-help] javacomm version 3 on Linux Ubuntu - serial
 port not receiving data
To: tinyos-help@Millennium.Berkeley.EDU
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"

Hi, I've installed javacomm version 3 on Ubuntu 'Gutsy Gibbon' and I've set up 
successfully,
but my code it's only capable of transmitting data and not receiving it (!!!).

SUMMARY:

Device: TMOTE IV
API: TinyOS 1.0.x
Comm: javacomm v3.0-u1
OS: Linux Ubuntu 'Gutsy Gibbon'
Driver USB-Serial: ftdi_sio included in the Linux kernel.

I'm using the /dev/ttyS0 port to communicate with the USB device on /dev/2-1 
via the ftdi_sio driver.

The problem isn't the port permissions:
crw-rw-rw- 1 root root 189, 129 2007-11-14 18:24 /dev/2-1
crw-rw-rw- 1 root dialout 4, 64 2007-11-14 18:22 /dev/ttyS0

I attatch my code because any person could help me. NOTE: This code works 
smoothly on Windows, and in Linux I can open the port and set up it, even send 
data, but I'm not receiving anything...

In the comments I read some warnings about working on Linux, but I don't fully 
understand them to modify the code.


*** CODE: ***

package net.tinyos.packet;

import java.util.*;
import java.io.*;
import javax.comm.*;
import javax.swing.JOptionPane;
 

/**
 * A serial port byte source, with extra special hack to deal with
 * broken javax.comm implementations (IBM's javax.comm does not set the
 * port to raw mode, on Linux, at least in some implementations - call
 * an external program (tinyos-serial-configure) to "fix" this)
 */
public class SerialByteSource extends StreamByteSource implements 
SerialPortEventListener
{
    private SerialPort serialPort;
    private String portName;
    private int baudRate;
   
    
    public SerialByteSource(String portName, int baudRate) {
 this.portName = portName;
 this.baudRate = baudRate;
    }

    public void openStreams() throws IOException {
 CommPortIdentifier portId = null;
 try {
     portId = CommPortIdentifier.getPortIdentifier(portName);
           
 }
 catch (NoSuchPortException e) {
           
           
          throw new IOException("Invalid port. " + allPorts());
        }   
 try {
     serialPort = (SerialPort)portId.open("SerialByteSource",
       CommPortIdentifier.PORT_SERIAL);
            String own = serialPort.getName();
 }
 catch (PortInUseException e) {
           throw new IOException("Port " + portName + " busy");
 }

 try {
     serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
     serialPort.setSerialPortParams(baudRate,
        SerialPort.DATABITS_8,
        SerialPort.STOPBITS_1,
        SerialPort.PARITY_NONE);

     serialPort.addEventListener(this);
     serialPort.notifyOnDataAvailable(true);
 }
 catch (Exception e) {
           serialPort.close();
     throw new IOException("Couldn't configure " + portName);
 }

 // Try & run external program to setup serial port correctly
 // (necessary on Linux, IBM's javax.comm leaves port in cooked mode)
 try {
     Runtime.getRuntime().exec("tinyos-serial-configure " + portName);
 }
 catch (IOException e) { }

 is = serialPort.getInputStream();
 os = serialPort.getOutputStream();
        
     
    }

    public void closeStreams() throws IOException {
 serialPort.close();
    }

    public String allPorts() {
 Enumeration ports = CommPortIdentifier.getPortIdentifiers();
 if (ports == null)
     return "No comm ports found!";

 boolean  noPorts = true;
 String portList = "Known serial ports:\n";
 while (ports.hasMoreElements()) {
     CommPortIdentifier port = (CommPortIdentifier)ports.nextElement();

     if (port.getPortType() == CommPortIdentifier.PORT_SERIAL) {
  portList += "- " + port.getName() + "\n";
  noPorts = false;
     }
 }
 if (noPorts)
     return "No comm ports found!";
 else
     return portList;
    }

    Object sync = new Object();

    public byte readByte() throws IOException {
 // On Linux at least, javax.comm input streams are not interruptible.
 // Make them so, relying on the DATA_AVAILABLE serial event.
 synchronized (sync) {
     while (is.available() == 0) {
  try {
      sync.wait();
  }
  catch (InterruptedException e) {
      close();
      throw new IOException("interrupted");
  }
     }
 }

 return super.readByte();        ///////// -> VIEW THE NEXT CLASS
    }

    public void serialEvent(SerialPortEvent ev) {
     
  // DEBUG
  System.out.println(this.getClass().getName()+ ": serialEvent: EVENTO.");

  if (ev.getEventType() == SerialPortEvent.DATA_AVAILABLE) {
   
   // DEBUG
   System.out.println(this.getClass().getName()+ ": serialEvent: DATOS 
DISPONIBLES.");
   
   synchronized (sync) {
    sync.notify();
   }
   
  }
  
     }

}



////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

package net.tinyos.packet;


import java.io.*;

abstract public class StreamByteSource implements ByteSource
{
    protected InputStream is;
    protected OutputStream os;
    private boolean opened;

    protected StreamByteSource() {
    }

    abstract protected void openStreams() throws IOException;
    abstract protected void closeStreams() throws IOException;

    public void open() throws IOException {
 openStreams();
 opened = true;
    }

    public void close() {
 if (opened) {
     opened = false;
     try { 
  os.close(); 
  is.close();
  closeStreams();
     }
     catch (Exception e) { }
 }
    }

    public byte readByte() throws IOException {
 int serialByte;

 if (!opened)
     throw new IOException("not open");

 try {
     serialByte = is.read();
 }
 catch (IOException e) {
      serialByte = -1;
 }

 if (serialByte == -1) {
     close();
     throw new IOException("read error");
 }

 return (byte)serialByte;
    }

    public void writeBytes(byte[] bytes) throws IOException {
 if (!opened)
     throw new IOException("not open");

 try {
     os.write(bytes);
     os.flush();
 }
 catch (IOException e) {
     close();
     throw new IOException("write error");
 }
    }
}

I'm going crazy with this, so any help would be wellcomed!!!

Thank you very much. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20071114/62191a87/attachment.htm

------------------------------

Message: 5
Date: Wed, 14 Nov 2007 11:39:54 -0700
From: Michael Schippling 
Subject: Re: [Tinyos-help] (yet another) Question about signal
To: Philip Levis 

Cc: tinyos-help@Millennium.Berkeley.EDU
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

OK, so I found
 nesC 1.1 Language Reference Manual (2003)
and
 The nesC Language:... (2003)

but in a quick search I don't find _what_ is the meaning of "signal",
except that it seems to be prefixed to calling functions labeled "event".
Do I need to really read the whole thing to get the idea, or is there
some summary that explains the hierarchy and impetus behind these keywords?
Or do I have to re-remember BNF?

thx
MS

Philip Levis wrote:
> 
> On Nov 14, 2007, at 10:05 AM, Michael Schippling wrote:
> 
>> I guess if I took the time to read and understand all the NESCC 
>> design/doc,
>> rather than wasting it on trying to make my own projects work, I wouldn't
>> be asking so many seemingly redundant questions. I expect the whole thing
>> has to do with using "async" as a flag to force race-condition 
>> evaluation,
>> which then blossomed into a chain of fix-the-boundary-cases keywords.
> 
> Not at all. The async keyword wasn't introduced until TinyOS 1.1.
> 
> Phil


------------------------------

_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

End of Tinyos-help Digest, Vol 55, Issue 53
*******************************************




       
---------------------------------
Get easy, one-click access to your favorites.  Make Yahoo! your homepage.
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to