3_7 funcard fix here

[niceday]

can any body help me make a fix for my fun card or atmega i am using infinity usb phoenix using a usb a to b cable

[timetrex]

I also have the avrstudio, I loaded up one of the last fixes and was trying to gey my bounds about the program and how to use it...

I do think it is important to understand some of the commands from nagra even though it may not be neccessary for the fix but it gives us some sort of grounding to move forward.

[dannyt0812]

From what I have seen so far the card is resetting itself becuase of a timing issue. It is timing itself out and thats why it is resettig. So as said earlier there is no problem with communication but the amount of time the card is given to respond. It looks as if the 3.7 is asking for a response from the card alot quicker than 3.6 is.

Could be barking completely up the wrong tree so if I am please let me no lol

[666]

Originally Posted by Tesla

I do tend to go for 'sexy' coding lol. Any fix is a good fix and if you get into this in any detail you will find there is always more than one way to end up with the same result.

5 ways so far

[timetrex]

was having a good read at stuntguy guide and what I found intresting was this

The NAD is used to route messages. The upper nibble of the NAD is defined
as the target address, and the lower nibble is defined as the source address.
In the NagraVision system, only two addresses are defined: Address 1 is the
receiver, and address 2 is the smartcard. Although 4 bits appear to be available for addressing, in reality, only the lower 3 bits of each nibble are available for addresses. The upper bit of each nibble is reserved for Vpp control requests. Since the NagraVision system doesn't use these bits, they won't be discussed here. Actually, it's also interesting to note that the smartcarts don't do any sanity checking on the NAD...they just assume that whatever NAD they received was the correct one and swap its nibbles when they
send a response.

What if the Nad is incorrect, Messages not getting routed correctly or wrong? Thus causing repeated IFS requests, it just seams that communication is an isuue and things seemed to be wired up wrong.

[Tesla]

@ SunRise - maybe but with nagra3 just around the corner its probably the last post of this type????

@ timetrex - The 3.7 problem I repeat is nothing to do with any commands or response to commands. I am not saying that a understanding of the command structure is wasted learning, its just not applicable to this problem.

@ PaddyBhoy - Back to basics, the fun/atmega cards run a simulation of of a nagra1 card, it has enough code to respond to the IRD (Integrated Reciever Decoder 'your box') in a way which will fool the IRD into thinking it is dealing with a osc card. The card has a avr prossesor at90s8515 funcard and atmega163/161 for the atmega. This means that all the code for these cards are the respective AVR code, for the fun card you need to obtain the prune source code, for the atmega you need to obtain the redneck source code. This source code is editable in a text editor or AVRstudio, when chages to the source code is made you assemble the code which produces the necessary HEX file which is the file you load onto your card.

[PaddyBhoy]

Originally Posted by Tesla

@ SunRise - maybe but with nagra3 just around the corner its probably the last post of this type????

@ timetrex - The 3.7 problem I repeat is nothing to do with any commands or response to commands. I am not saying that a understanding of the command structure is wasted learning, its just not applicable to this problem.

@ PaddyBhoy - Back to basics, the fun/atmega cards run a simulation of of a nagra1 card, it has enough code to respond to the IRD (Integrated Reciever Decoder 'your box') in a way which will fool the IRD into thinking it is dealing with a osc card. The card has a avr prossesor at90s8515 funcard and atmega163/161 for the atmega. This means that all the code for these cards are the respective AVR code, for the fun card you need to obtain the prune source code, for the atmega you need to obtain the redneck source code. This source code is editable in a text editor or AVRstudio, when chages to the source code is made you assemble the code which produces the necessary HEX file which is the file you load onto your card.

cheers i will look at how the card is constructed within AVR as i now have the prune source

[TheCoder]

AVRStudio is a fairly complex program as it contains a full Atmel core simulator as well as interfaces for various debugging interfaces from real processors (jtag-like things etc).

Mostly, when dealing with Funcard/ATMega cards, the majority of people would initially use the stand alone assembler that comes with one of the source card packages (cant remember which one it is). The assembler that comes with this package is a simple command line driven thing but there's usually a batch file to make building even easier.

AVRStudio is really only used for complex debugging sessions. In this particular case AVRStudio doesn't really have any advantage as the problem is not something that can be easily simulated.

[666]

Originally Posted by Tesla

@ SunRise - maybe but with nagra3 just around the corner its probably the last post of this type????

@ timetrex - The 3.7 problem I repeat is nothing to do with any commands or response to commands. I am not saying that a understanding of the command structure is wasted learning, its just not applicable to this problem.

@ PaddyBhoy - Back to basics, the fun/atmega cards run a simulation of of a nagra1 card, it has enough code to respond to the IRD (Integrated Reciever Decoder 'your box') in a way which will fool the IRD into thinking it is dealing with a osc card. The card has a avr prossesor at90s8515 funcard and atmega163/161 for the atmega. This means that all the code for these cards are the respective AVR code, for the fun card you need to obtain the prune source code, for the atmega you need to obtain the redneck source code. This source code is editable in a text editor or AVRstudio, when chages to the source code is made you assemble the code which produces the necessary HEX file which is the file you load onto your card.

agree, this will props be the last fix for the fun, ashamed to say i only took interest now.

[PaddyBhoy]

Originally Posted by 666

agree, this will props be the last fix for the fun, ashamed to say i only took interest now.

Aye one good thing has come about with this problem, rather than let someone else fix for me i'm determined to fix it myself.I have my box running on a mosc at the moment so it doesnot really effect me that much.