View unanswered posts | View active topics It is currently Sun Sep 21, 2014 8:57 pm






Reply to topic  [ 6 posts ] 
Hitechnic Accel, cable lenght 
Author Message
Rookie

Joined: Mon May 12, 2008 3:44 pm
Posts: 2
Location: Canada
Post Hitechnic Accel, cable lenght
Hi,

I use the Hitechnic Accel Sensor for my project and i have a problem.

When i use the sensor with a 17cm (7") cable, the sensor work great. But it doesn't work with a 50cm cable or higher. I try a couple of cable but i have the same problem.

The I2C error is -35

For my project i need to use the 90cm cable.

I use the 1.30 version and try it also on the 1.05 version.


Here’s the program.

Quote:
//INITIALISATION//
void closeWriteTextFile();
void writeNewLine();
void writeIntegerNumber(long nNumber);
bool bFirstNumberOnLine = true;
TFileIOResult nIoResult = ioRsltSuccess;
TFileHandle hFileWriteHandle = NOT_A_HANDLE;
string sFileName = "01FILE.dat";
int nNumber ;
int nTime;
int ClockTime;
int xVal,yVal,zVal;
tSensors myPort= S1;
const int kMaxFileSize = 20000;
byte replyMessage[6];
string sFileNameSearch;
short nFileSizeSearch;
short hFileHandleSearch;
TFileIOResult nIoResultSearch;




//Sous-routine TITRE FICHIER TEXTE//
void FileSearch()
{

FindFirstFile(hFileHandleSearch, nIoResultSearch, "01FILE.dat", sFileNameSearch, nFileSizeSearch);
if(nIoResultSearch == 0)
{sFileName="02FILE.dat";}

FindFirstFile(hFileHandleSearch, nIoResultSearch, "02FILE.dat", sFileNameSearch, nFileSizeSearch);
if(nIoResultSearch == 0)
{sFileName="03FILE.dat";}

FindFirstFile(hFileHandleSearch, nIoResultSearch, "03FILE.dat", sFileNameSearch, nFileSizeSearch);
if(nIoResultSearch == 0)
{sFileName="04FILE.dat";}

FindFirstFile(hFileHandleSearch, nIoResultSearch, "04FILE.dat", sFileNameSearch, nFileSizeSearch);
if(nIoResultSearch == 0)
{sFileName="05FILE.dat";}

Close(hFileHandleSearch, nIoResultSearch);

nxtDisplayTextLine(0, sFileName);
wait1Msec(1000);

}



//Sous-routine OUVERTURE FICHIER TEXTE//
bool bOpenWriteTextFile(const string &sFileName, int nFileSize)
{
bFirstNumberOnLine = true;
Delete(sFileName, nIoResult);
OpenWrite(hFileWriteHandle, nIoResult, sFileName, nFileSize);
return nIoResult == ioRsltSuccess;
}


//Sous-routine FERMETURE FICHIER TEXTE//
void closeWriteTextFile()
{
Close(hFileWriteHandle, nIoResult);
hFileWriteHandle = NOT_A_HANDLE;
}


//Sous-routine SAUT DE LIGNE//
void writeNewLine()
{
WriteText(hFileWriteHandle, nIoResult, "\r\n");
bFirstNumberOnLine = true;
return;
}



//Sous-routine ESPACE//
void writeDelimiterBetweenNumbers()
{
if (bFirstNumberOnLine)
bFirstNumberOnLine = false;
else
WriteText(hFileWriteHandle, nIoResult, "\t");
return;
}


//Sous-routine ECRITURE INTEGER//
void writeIntegerNumber(long nNumber)
{
string sTemp;
writeDelimiterBetweenNumbers();
StringFormat(sTemp, "%d", (long) nNumber);
WriteText(hFileWriteHandle, nIoResult, sTemp);
return;
}



//Sous-routine ECRITURE FICHIER TEXTE//
void WriteTextFile(int val)
{
nTime = time1[T1] / 100;
writeIntegerNumber(nTime);
writeDelimiterBetweenNumbers();
nNumber = val;
writeIntegerNumber(nNumber);
writeNewLine();
wait10Msec(10);
}



//Sous-routine INIT TEXT//
void InitTextFile()
{
ClearTimer(T1);
nTime = 0;
bOpenWriteTextFile(sFileName, kMaxFileSize);
}




int readIC(tSensors port, int hexAdd)
{
typedef struct
{
byte nMsgSize;
byte nDeviceAddress;
byte nLocationPtr;
byte nData;
} TI2C_Output;

TI2C_Output sOutput;

sOutput.nMsgSize = 2;
sOutput.nDeviceAddress = 0x02;
sOutput.nLocationPtr = hexAdd;
sOutput.nData = 0x00;
SensorType[port] = sensorI2CCustomFast;

wait10Msec(5);
nI2CBytesReady[port]=0;
sendI2CMsg(port, sOutput.nMsgSize, 0);
while(nI2CStatus[port]== STAT_COMM_PENDING)
wait1Msec(2);

byte replyMessage[4];

nI2CBytesReady[port]=0;

sendI2CMsg(port,sOutput.nMsgSize ,4);

while (nI2CStatus[S1]==STAT_COMM_PENDING)
wait1Msec(5);

if (nI2CStatus[port]==NO_ERR)
{
readI2CReply(port, replyMessage[0], 4);

int ret =(replyMessage[0]*4)+replyMessage[3];

if(ret > 511)
ret -= 1024;
return ret;
}
else
{
nxtDisplayTextLine(3, "i2c err %d", nI2CStatus[S1]);
}

return 0;
}





task main()
{
FileSearch();
InitTextFile();

while( nNxtButtonPressed == -1 )
{
xVal = readIC(myPort, 0x42);
nxtDisplayTextLine(4, "CAPTEUR #1: %d", xVal);
ClockTime = time1[T1] / 1000;
nxtDisplayTextLine(1, "TEMPS: %d sec", ClockTime);
WriteTextFile(xVal);
}
eraseDisplay();
nxtDisplayTextLine(4,"FIN DU PROGRAMME");
wait10Msec(50);
closeWriteTextFile();
}



Mon May 12, 2008 4:05 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 603
Post 
Hi there,

To test with your longer cable, try running the I2C in the "slow-bus" mode by using the sensor type sensorI2CCustom instead of sensorI2CCustomFast.

This is a known issue with longer I2C cables with HiTechnic sensors. We're currently working on a fix to solve this issue.

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Tue May 13, 2008 9:24 am
Profile
Rookie

Joined: Mon May 12, 2008 3:44 pm
Posts: 2
Location: Canada
Post 
I try sensorI2CCustom instead sensorI2CCustomfast and i got the same result...

Even with the "Accel Try me Software" of the 1.30 version, it doesn't work. :|


Tue May 13, 2008 11:28 am
Profile
Rookie

Joined: Sat Apr 12, 2008 11:09 am
Posts: 49
Location: holland
Post 
Hello,

I have the same problem. I also tested with NXT-G software. Here it works fine.


Sun May 18, 2008 11:27 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
Unfortunately long length cables are not officially supported by LEGO. The extra length adds enough extra capacitance to the cable to slow the "rise time" of signals such that the messaging can occassionally get corrupted.

Notwithstanding above, most I2C sensors seem to work OK with long length cables. Currently, NXT-G firmware performs better than ROBOTC firmware with this. The ROBOTC firmware C-code has been optimized for performance which accentuates the problem.

I've just discovered a "Day One" bug in the firmware (NXT-G and ROBOTC) where the clock wire and and data wire are changed simultaneously in the same time slice. The "extra capacitance causes the sensor to see the data change before the clock change corrupting the I2C messaging. The problem is worse in ROBOTC firmware because of the optimized C-code.

The fix is to insert additional delay in the C-code between changing the clock line and the data line. This fix has been made in the ROBOTC firmware and will be included in the next pre-release version -- which should be posted sometime this week.


Mon May 19, 2008 10:15 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
This fix is in 1.36 release. With a 90 cm cable, I get zero errors in 10K messages using the HiTechnic compass


Wed Jun 04, 2008 6:09 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 6 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.